Live on Ethereum Sepolia & Tron Nile testnets
Run the SDK.
Watch the chain answer.
Seven snippets, each one real. Edit them, run them, and every await below is an actual HTTP call to a public Varnir testnet node — no simulation, no recorded fixtures, no mock responses. Four of them commit real transactions to a real ledger.
Testnet only. This is a sandbox, not a wallet.
- Keys are generated in your browser and stay there. The private half is never transmitted anywhere — only signatures your own code produces are.
- They live in memory for this tab and nowhere else. Reloading destroys them. Nothing is written to storage, and that is deliberate.
- These are throwaway keys on public test networks with no real value. Do not fund them and do not reuse them for anything real.
Two agents, one treasury
A procurement agent decides what to buy and asks to pay for it. A treasury agent decides whether that is allowed. Neither can do the other's job, and the ledger holds the terms in between — so a payment cannot be redirected or resized after it was agreed, even by the agent that approves it.
simulated the judgement — which vendor, how much, approve or hold — comes from a seeded random and a timer. real every SDK call, every signature, and every transaction below actually happens on the public testnet. Swap the two decision functions for model calls and nothing else changes.
Then the same two agents trade with each other. A swap here is not a pool or a bridge — both sides are balances on one ledger, so each party simply moves what it holds to the other. That is why the second trade is cross-chain and looks identical to the first: Tron USDT one way and Sepolia ETH the other is the same operation twice. Nothing is wrapped, nothing is staked, and at no point does a third party hold both sides.
Where this goes next
What you just ran is the opening of a settlement flow: an identity that holds its own keys, an L1 deposit address bound to it on-chain, and requests authorised by signatures rather than by a bearer secret sitting on a server. The documentation covers the rest — deposits, invoices, and the verification model that decides whether an agent's intent to pay executes at all.