What Varnir is
Varnir is building a payment rail designed for software agents to use directly — including AI agents that need to hold, receive and move value as part of doing their job.
The part that makes that safe is a treasury-control model where one agent's intent to pay is verified by other agents before it executes, rather than a single model being able to move funds on its own say-so. That verification layer is the goal the rest of the system is being built toward.
Everything described in these docs runs on public test networks — Ethereum Sepolia and Tron Nile. No component here handles real funds, and the multi-agent treasury-approval layer described above is not built yet. What is built is the settlement layer, wallets, invoicing and the SDK underneath it, and that part is real and running. This page is explicit about which is which.
What exists today
| Piece | What it does |
|---|---|
| Settlement layer | A custom ActiveLedger fork running as a four-node testnet, with the wallet/transfer/onboarding logic written as on-ledger contracts |
| Block explorer | Public scanner over the ledger and the two L1 testnets it watches |
| Web wallet | Lightweight browser wallet — onboard an identity, get a wallet assigned, send and receive |
| Invoicing | Named, referenced, multi-wallet invoices with payment detection (reference) |
| Webhooks | HMAC-signed deposit callbacks, pending then confirmed (reference) |
| SDK | @varnir/chain-client + @varnir/signing — everything the web wallet does, from your own code (getting started) |
| Mobile wallet | An Expo / React Native wallet app, in development |
The one property worth understanding first
A private key never reaches a Varnir-operated server. This is not a policy or a roadmap item — it is how the code is shaped, everywhere:
- Identity keys are generated in your process (browser, phone, or your own server) and stay there.
- Every ledger transaction is signed locally and POSTed directly to a chain node, not relayed through a Varnir API that could have signed it for you.
- The one thing Varnir's own API is asked for during wallet setup is which wallet id to claim — a public, unauthenticated read. It hands out ids; it does not decide who gets one, and it cannot assign one to you. Assignment is a transaction signed by your identity's own key.
- API keys for the bookkeeping endpoints are a separate secp256k1 keypair from your identity key, and only the public half is ever transmitted. Requests are signed, not bearer-authenticated. See API keys.
Read Getting started to see the whole flow, or The signing model for the cryptographic detail.
That covers your identity key. The L1 wallet keys that actually receive deposits are a separate question — those the network does hold, and How keys are held is the full account of how they are split so that no single node, operator or jurisdiction can sign with one. Distribution and jurisdiction states plainly which parts of that are deployed today and which are not.
Where this is going
The current stack settles value between identities. The layer being built on top of it is treasury control for agent-initiated payments: an AI proposes a payment, independent verifying agents check it against policy, and only an approved proposal becomes a settled transaction. A near-term target use case is USDT settlement in the Eurozone.
That layer is stated here as a direction, not a feature. Nothing in this documentation describes it as available, because it isn't.