Mainnet payouts, step by step

On 2026-11-13 the vault v0.probarion.near paid the owner's own Base wallet 0xB22EAcDf11177d6D635E8956BBbBdd54B3E6EB27 twice through NEAR Intents, as tests. Spend 2 burned 1.00 USDC on NEAR mainnet, and the POA bridge delivered 0.9976 USDC, 997600 in base units, in Base block 56821514: code refused two attested model proposals for its invoice, then the code rules alone allowed the payment. Spend 3 burned 0.25 USDC, and the bridge delivered 0.2476 USDC, 247600 in base units, in Base block 56898526: an attested model proposed it, and the code rules allowed it. In both, the agent's spend call named no address: the vault took the payee from the mandate the owner signed. Every step is on chain, and you can check each one with no wallet and no key.

Spend 2 at a glance#

The run's files are in docs/evidence/mainnet-v0/s1-2026-11-13 (opens in a new tab): the signed ledger, the snapshot, the verifier's output, the invoice and purchase order, the POA bridge and 1Click statuses, and the order of every transaction.

Spend 3 at a glance#

The run's files are in docs/evidence/mainnet-v0/s2-2026-11-13 (opens in a new tab): the whole signed ledger, the snapshot, the verifier's output, the invoice and purchase order, the outcome and the spend's decision, the POA bridge status, the Base receipt, the gas record and the order of every transaction.

Check it in your browser#

Nothing here needs a wallet, a key or an account.

• Read the chain again. Open the mainnet section of the landing page. Spend 3, the newest payout, shows at the top, open: press Read the chain now in its card. Your browser reads 4 transactions and 3 views from public RPC and runs the seven checks below. When every answer matches, the verdict line above the checks says "Read just now: 7 of 7 checks pass." A node that does not answer leaves its rows on the recorded values, marked "Could not read".
• Read spend 2 again. Spend 2 is folded under spend 3. Open it with "Show its seven checks and its ledger", and press its own Read the chain now. It reads spend 2's transactions and views in the same way.
• Open the burns on nearblocks. Spend 2 (opens in a new tab) shows the vault's spend, its ft_withdraw call to intents.near, and the ft_burn of 1000000 with the memo WITHDRAW_TO:0xB22EAcDf11177d6D635E8956BBbBdd54B3E6EB27. Spend 3 (opens in a new tab) shows the same calls, with an ft_burn of 250000 and the same memo.
• Open the arrivals on Basescan. Spend 2's transfer (opens in a new tab) shows 0.9976 USDC moving to 0xb22eacdf11177d6d635e8956bbbbdd54b3e6eb27, and spend 3's (opens in a new tab) shows 0.2476 USDC, both on the USDC contract 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913.

The seven checks#

The landing page runs these seven checks in your browser for each payout, in the order of the route from NEAR to Base. The values are the ones the recorded run read from mainnet on 2026-11-13, and a live run must read the same.

Spend 2#

Spend 3#

How the page reads them:

• Pinned views. The three views, get_config, view_access_key and view_account, are read at the block of each spend, which the spend's own outcome names: for spend 2, GM4ojam5J4e91NpzMF1BdbjF65wJcVPvbF6bijT37FTa (height 224331722), and for spend 3, B7iXoHCJHWLPWbLNispMCJBzSYC5oD8XqEuZr59MvWeB (height 224358455). A later change to the vault cannot change their answers, and a check fails when an answer comes from another block.
• Public hosts. Every NEAR read asks FastNEAR's archival node, archival-rpc.mainnet.fastnear.com, then the regular node, rpc.mainnet.fastnear.com. The regular node forgets old transactions within days. The Base read asks mainnet.base.org. Each request gives up after 8 seconds and is tried up to twice more, when a retry can help, after 0.5 and 1.5 seconds, before the next host. An answer for another transaction, or one that is not final, goes to the next host. So a NEAR read takes at most 52 seconds, and the Base read 26.
• Nothing in between. The requests go from your browser to those hosts, with no cookies and no referrer, and none goes through Probarion's server. They change nothing and sign nothing.
• Not the verifier. The seven checks read the chain again, and check 06 hashes the two ledger entries the page carries for each payout. They do not check the entries' signatures or the rest of the file: the verifier does, see Run the verifier.

How the payments were decided#

Spend 2: two refusals, then the code rules alone#

The owner set up the run the same day:

• A top-up through NEAR Intents 1Click. The owner's wallet sent 1.5 native USDC to a 1Click deposit address (transaction (opens in a new tab)), and 1Click credited 1.499823 Base USDC to the vault's balance inside intents.near (settlement (opens in a new tab), signed by 1Click).
• A ledger key. set_ledger_key added ed25519:RY7kjsaRStq4gt27RpNgErr9AjuKuZdzCXd6atSrzKK, a function-call key on the vault that can call anchor and nothing else (transaction (opens in a new tab)).
• Mandate 2. The owner's own Base wallet, up to 1.00 USDC, 1 use, until 2026-11-20 (transaction (opens in a new tab)).

Then the SDK ran three cycles on INV-M002. Cycles 1 and 2 each wrote one signed entry and anchored the ledger before the next cycle began. Cycle 3 wrote entries 2 and 3, then anchor 3:

Why code refused the two proposals. Both models proposed the right amount and the right Base address. Both also put the mandate's asset account, base-0x833589fcd6edb6e08f4c7c32d4f71b54bda02913.omft.near (Base USDC as a NEAR token), in the payee hint's near_account field. The SDK the owner ran, at commit 4ab41ca, took any NEAR account in the hint as a contradiction for a mandate that pays a Base address (payeeHintContradiction in packages/core/src/policy.ts (opens in a new tab) at that commit). The rule's words in entry 0: "invoice names NEAR account base-0x833589fcd6edb6e08f4c7c32d4f71b54bda02913.omft.near; the mandate pays base:0xB22EAcDf11177d6D635E8956BBbBdd54B3E6EB27". The rule, as it ran, had no case for a Base mandate's own asset account, so both were false refusals: the amount and the Base address were right, and they cost two tries and no money. After the run, PR #142 (opens in a new tab) changed the rule for a model's hint. In an invoice it is still refused. Why spend has no payee explains the rule.

Why the code rules alone decided the payment. The owner ran the cycle a third time with no model. The SDK decided with the code rules alone, and every rule passed. Entry 2's body hash, d64f0de77c38294cf103439e6b5b0c2623b96b114962afd50f5a3c553df2a336, is the decision_hash the spend carries, so the spend points at its own decision.

Spend 3: an attested model and the code rules#

The owner set up the second round the same day, with one transaction:

• Mandate 3. The owner's own Base wallet, the payee of mandate 2, up to 0.25 USDC, 1 use, until 2026-11-20 (transaction (opens in a new tab)).

The round added no USDC and no key. It paid from the 0.499823 Base USDC that spend 2's round left inside intents.near, and it wrote on the same ledger with the same ledger key. The kit ran the SDK at commit c85f41b, which holds PR #142 and PR #144 (opens in a new tab). It ran one cycle on INV-M003, which wrote entries 4 and 5, then anchor 4:

Why code refused nothing this time. The model answered on attempt 1, in 38.2 seconds. Its payee hint named the mandate's Base address and no NEAR account, so mandate.payee_mismatch passed on the address alone. The 16 rules are the 14 of entry 2 plus model.refused and model.low_confidence, which passed with the action pay and a confidence of 0.92 over the floor of 0.7. The rule changes of PR #142 and PR #144 read a mandate's own asset account in a hint, and this hint gave them nothing to read, so they were not exercised on mainnet.

What the attestation shows. Before the SDK counted the answer, it checked the model's evidence: the signature, the response, the recorded proposal and the attestation report agree with each other and with ledger position 4 (A1 to A7), and the request matches the invoice text (A8). Entry 4's body hash, d3807956b1e0a0481656862a50a2147d2b0a1f04834a30829529311c9cec32aa, is the decision_hash spend 3 carries. The TDX quote and the GPU evidence are checked by verify --online (O1 and O2), which passed on this decision in a read-only run at 17:52 UTC on 2026-11-13 (output (opens in a new tab)), and the TEE measurement is not pinned, so this does not show which model image ran.

The ledger and its anchors#

The ledger key signs every entry, and each entry links the hash of the one before it. Each anchor stores on the vault how many entries it covers and their root. Ledger and anchors explains the format.

Each refusal was anchored on chain before the next cycle began, so the vault held a root covering both refusals before spend 2 was sent. Anchor 4 came after spend 3 and covers all 6 entries. There are two ledger files, byte for byte as the runs wrote them: spend 2's (opens in a new tab) holds entries 0 to 3, and spend 3's (opens in a new tab) holds entries 0 to 5. Spend 3's file starts with spend 2's file, byte for byte.

Run the verifier#

The verifier checks the ledger file against the chain. It reads public mainnet data and signs nothing. Build the CLI from a clone, since the commands below read the ledger, the invoice texts and the evidence from its docs folder:

git clone https://github.com/probarion/probarion
cd probarion
pnpm install
pnpm --filter "{packages/cli}..." build

With the ledger of 6 entries#

Run it live, with the ledger file that holds both payouts, the two invoice texts for A8, the repository's evidence for spend 1 and the recorded transactions:

node packages/cli/dist/bin.js --network mainnet --rpc https://rpc.mainnet.fastnear.com verify --vault v0.probarion.near --ledger docs/evidence/mainnet-v0/s2-2026-11-13/ledger-2026-11-13.jsonl --invoice docs/evidence/mainnet-v0/s1-2026-11-13/invoice-INV-M002.txt --invoice docs/evidence/mainnet-v0/s2-2026-11-13/invoice-INV-M003.txt --evidence docs/evidence --proof docs/mainnet-proof.json

The kit's live run at 11:41:26 UTC on 2026-11-13 ended with these two lines (the full output (opens in a new tab)):

8 passed, 0 failed, 0 unproven, 1 skipped
RESULT: PASS

What each check found:

• Checks a, b and c: the 6 entries carry valid signatures by the ledger key, their hash links recompute from the zero link, and the 4 anchors on chain match the ledger.
• Check d: spends 2 and 3 are each bound to their own allow decision, entries 2 and 4, with the same invoice, mandate and amount. Spend 1 of 2026-11-11 is exempt: its decision is a file in the repository, from before the vault had a ledger.
• Check e: the 3 attested decisions, entries 0, 1 and 4, pass A1 to A7, and A8 passes on all three with the two invoice texts. Entry 2 is reported as decided by code rules with no model, not failed.
• Checks f and g: no full-access key, every key is the ledger key or the agent key, and no key is registered for the vault in intents.near.
• Check h: spends 2 and 3 each have one matched burn pair, the ft_burn memo and the vault's mt_burn for the spend's amount.
• Check i skips: no factory made this vault.

The kit ran these checks from its own SDK clone at c85f41b, with the two burn transactions given with --burn-tx in place of --proof, because that commit's proof file had no spend 3, and with the invoices read from its own folder. The command above, with --proof docs/mainnet-proof.json and the committed invoices, gives the same counts.

Without --ledger, checks c and d fail: the chain's anchors cover 6 entries, and the spends' decisions are in no entry. With spend 2's ledger file of 4 entries, check c fails, because the chain's last anchor covers 6 entries, and check d fails, because spend 3's decision is in none of them. A live run passes while the chain's anchors cover the entries the file holds. When the vault anchors a later entry, use the ledger file that holds it.

To check this run with no network, read the snapshot the verifier wrote at 11:41:25 UTC:

node packages/cli/dist/bin.js verify --offline docs/evidence/mainnet-v0/s2-2026-11-13/snapshot-2026-11-13.json --invoice docs/evidence/mainnet-v0/s1-2026-11-13/invoice-INV-M002.txt --invoice docs/evidence/mainnet-v0/s2-2026-11-13/invoice-INV-M003.txt

The run after spend 2#

Before spend 3, the kit's live run at 07:24:43 UTC read spend 2's ledger file of 4 entries and INV-M002, and it ended with the same two lines (the full output (opens in a new tab)). Checks a to c passed on 4 entries and the 3 anchors on chain then. Check d bound spend 2 to entry 2. Check e found 2 attested decisions, entries 0 and 1, that pass A1 to A7, and A8 on both with the invoice text. Check h found spend 2's burn pair. To check that run with no network, read the snapshot the verifier wrote at 07:24:42 UTC:

node packages/cli/dist/bin.js verify --offline docs/evidence/mainnet-v0/s1-2026-11-13/snapshot-2026-11-13.json --invoice docs/evidence/mainnet-v0/s1-2026-11-13/invoice-INV-M002.txt

The Base side#

The Base side is not in the ledger: entries 3 and 5 record the burns on NEAR. To read the transfers with no key, ask Base's public RPC:

curl -s https://mainnet.base.org -H 'content-type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["0xc2df8f8799467834cdaed0e8f23638af49334483387560fd34ef360939e1ea71"]}'
curl -s https://mainnet.base.org -H 'content-type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["0xc6c4507e098b558bdff1b5836600f5e3365fee5a63037d399db58e1db4547ab7"]}'

Spend 2's answers "status":"0x1" and "blockNumber":"0x363070a" (56821514), with one Transfer log on the USDC contract, from 0x2cff890f0378a11913b6129b2e97417a2c302680 to 0xb22eacdf11177d6d635e8956bbbbdd54b3e6eb27, whose data ends in f38e0: 997600. Spend 3's answers "status":"0x1" and "blockNumber":"0x36433de" (56898526), with one Transfer log between the same two addresses, whose data ends in 3c730: 247600.

The fee and the cost#

• The bridge fee. For spend 2 the vault burned 1000000 and the owner's wallet received 997600, and for spend 3 it burned 250000 and the wallet received 247600. The POA bridge's statuses say withdrawal_fee 2400 for each (spend 2 (opens in a new tab), spend 3 (opens in a new tab)). Probarion took none.
• The top-up. 1Click took 1500000 of native USDC and credited 1499823 of Base USDC to the vault inside intents.near (status (opens in a new tab)). The vault kept 0.499823 Base USDC there after spend 2, and 0.249823 after spend 3.
• The gas. Spend 2 burned 15.35 Tgas, 0.001423 NEAR, and spend 3 burned 15.36 Tgas, 0.001424 NEAR, each summed over the transaction and every receipt, read from an archival node (spend 2 (opens in a new tab), spend 3 (opens in a new tab)). Limits and costs lists the gas the contracts attach.

The NEAR technology in these runs#

Where to go next#

• Testnet and mainnet covers the mainnet vault and its run of 2026-11-11.
• Verify a vault walks the verifier on a testnet vault, offline and live.
• Verifier checks says what each check proves.
• Vaults, roles and keys covers the agent key and the ledger key.

What this does not do#

• They are tests, not customer payments. Two payouts, of 1.00 USDC and 0.25 USDC, went to the owner's own Base wallet: one decided by the code rules alone, one proposed by an attested model and allowed by the code rules. They show the cross-chain path works on mainnet for this vault. They do not show a business paying a supplier.
• By 2026-11-13, one mainnet payment had come from a model's proposal. Spend 1 of 2026-11-11 was sent without the SDK, spend 2 was decided by the code rules alone, and spend 3 was proposed by an attested model and allowed by the code rules.
• The model hint fix came after spend 2's run. After it, PR #142 (opens in a new tab) changed payeeHintContradiction: in a model's hint, a Base or Solana mandate's own asset account names no other payee. In an invoice it is still refused. Spend 2's run used the code before it, at commit 4ab41ca. Spend 3's run used commit c85f41b, which holds it, but its hint named no NEAR account, so the change was not exercised.
• The attestation does not show which model image ran. A1 to A8 passed on entries 0, 1 and 4, and a later read-only run of verify --online passed O1 and O2 on all three (output (opens in a new tab)). The TEE measurement is not pinned, so the record does not show which model image ran.
• The contract checks the burn, not the arrival. The vault's part ends with the burn on NEAR. The POA bridge releases the USDC on Base, and check 07 reads that from Base.
• No console or proof page serves this vault. Both serve testnet. The mainnet factory is not deployed, so the console cannot create a mainnet vault yet.