Copied from docs/measurements.md  at build time. Edit that file.

zx402: Measurements

Fill this file during M0. It replaces the estimates in SPEC.md section 10. Measured values that are already known are in research/2026-10-06-measurements.md .

1. Circuits

The setup power is the smallest one that fits the circuit. snarkjs needs one row per constraint, one per public signal, and one more. One shared powers of tau file of power 16 serves all three circuits. Its size is 113,248,170 bytes. The proving key sizes are for the development keys. Proving times were measured on an Apple M2 Max with Node 24.10.0 and snarkjs 0.7.6, while other builds ran. Each time covers the witness, the proof, and a check of the proof.

2. Scripts

Measured on 2026-10-06 with Aiken 1.1.24 and the development verification keys. The pool script takes the three verification keys as parameters, which adds about 2,600 bytes. The pool script fits one publication transaction (limit 16,384 bytes). Its reference output locks 55.5 ADA at the current price per byte. Script hashes depend on the deployment and are filled in after the live run.

3. Transactions on mainnet

Transactions on the local test chain

Measured on 2026-10-06 in packages/txlib/test/flow.test.ts, with the real validators, real proofs, and Preprod parameters. Execution units include the 10 percent margin that the builders add. Sizes include signatures.

So one private payment in stealth mode costs about 0.85 ADA in network fees for its two legs, before the relayer fee.

Transactions on Preprod

The Preprod pool was deployed on 2026-10-06. Its record is deployments/preprod.json .

A deployment costs about 245 ADA: 160 ADA of role funding, 73.6 ADA locked in the four reference script outputs, 8.9 ADA in the three state outputs, and about 1.5 ADA of fees. The Init units are the evaluated units before the 10 percent margin.

The first Init on Preprod was finished by hand, after the node refused it for a wrong script integrity hash. That defect is fixed in packages/txlib (live cost models). To prove the fix, the complete deploy function ran once more on Preprod on 2026-10-06 with the final code, as a rehearsal for mainnet. All four transactions were accepted on the first try, and the run took 201 seconds. That second pool is a rehearsal and is not recorded in this repository.

The rows from Deposit to Ragequit are one complete pool story, run on 2026-10-06 with the code of this repository. The indexer, the crank, the association set provider service and the relayer ran in one process against Blockfrost. The sizes, fees and units in those rows are the values that the chain recorded. A deposit of 10 ADA was credited as 9.7 ADA. A private payment of 2 ADA reached the seller from a one-time address. The change note of 6.534303 ADA then left the pool through Ragequit. For the same shape of transaction, the live units of Refund, Settle, Insert of 1 note and Ragequit are within 0.4 percent of the local test chain. The association update is 5 percent higher on Preprod. So one private payment in stealth mode cost 0.849327 ADA in network fees for its two legs, before the relayer fee of 1 ADA.

The demo through the node and the stock x402 seller

On 2026-10-06 the node (npm run node -w ops), the example seller with the stock x402 server and facilitator, and the demo (npm run demo -w ops) ran as three processes against Preprod. The demo ran four times with the same note store. All four runs ended with HTTP 200 and the weather body. Two later runs are at the end of this section. The agent paid through the stock x402 client with the SDK’s stealth signer. The stock facilitator checked and submitted the second leg. The first and second run, between 15:44 and 15:57 UTC, used the first version of the node. The third run, at 18:00 UTC, used the hardened SDK and the first node that skips work while nothing changes. The fourth run, at 19:23 UTC, used the final code with the two latency fixes that section 4 describes.

Pool transactions change in size as the pool ages, for two reasons. Each Insert adds one root of 35 bytes to the root history in the pool datum, until the history holds its 16 roots. A run makes two Inserts, so each kind of pool transaction is about 70 bytes larger in the next run. A full history makes a pool transaction 525 bytes larger than in a new pool. The size alone then adds 0.0231 ADA to its fee. The proof for a new nullifier also changes with the place of that nullifier in the trie. It made a Settle or a Ragequit up to 139 bytes larger or smaller from one run to the next.

Two runs after the comparison with Base

A comparison with the Base implementation then led to five fixes in the SDK and the relayer. Two more demo runs checked them on Preprod. Both ended with HTTP 200 and the weather body.

The fifth run, at 20:50 UTC on 2026-10-06, started without the demo’s note store and with the same seed. Before the fix, that run would have used an old note secret again and locked its deposit. The SDK found the four old deposits on chain. It took the fifth deposit secret and the fifth change secret, paid the seller and exited the change. The sixth run, at 21:13 UTC, used the final code with all five fixes and the note store of the fifth run.

During the fifth run the machine also ran two test suites that make proofs. So its time to a spendable note says nothing about the code. In the sixth run Preprod made no block for 132 seconds after the block of the Settle. The payment to the seller entered the next block, so the seller answered after 178 seconds. The code did not cause that wait. Since the fixes, a private payment makes two more requests to the agent’s provider: one for the fee rate and one for the tip. A deposit through the SDK makes one sync first.

The tUSDM pool

On 2026-10-07 the pool asset changed from ADA to tUSDM, the Preprod stablecoin of Masumi (policy 16a55b2a349361ff88c03788f93e1e966e5d689605d044fef722ddde, name 0014df10745553444d, 6 decimals). The same validators and the same proving keys serve the new pool; only the asset parameter of the pool script changed. The deploy sent four transactions and took about four minutes.

The pool ID is d433ba1cc677f8771f22b0ecbbbdcda504022b96f34eeaed39fae78c. The ADA pool from 2026-10-06 is retired; its record is in deployments/retired/.

The demo ran once against the tUSDM pool, at 03:44 UTC on 2026-10-07. It deposited 10 tUSDM, paid the seller 2 tUSDM through the stock x402 client, and exited the change of 7 tUSDM in public. It ended with HTTP 200 and the weather body.

What the outputs show, read from the chain:

• The deposit output held 10 tUSDM and 1.392130 ADA, the measured minimum for that output. The Insert credited the whole 10 tUSDM, and the crank kept the deposit’s ADA.
• The Settle left the pool with 7 tUSDM and its 6 ADA. The one-time address got exactly 2 tUSDM and 2 ADA. The relayer’s change got 1 tUSDM, its fee, and the relayer paid the 2 ADA and the network fee from its own ADA.
• Leg 2 paid the seller 2 tUSDM and 1.831927 ADA, which is the attached 2 ADA minus the fee. No change output.
• The exit paid the user 7 tUSDM and 1.055950 ADA, which is the measured minimum. The pool ended with no token entry and its 6 ADA.

Block times: deposit 03:44:53, Insert 03:45:42, ASP update 03:46:44, Settle 03:47:16, seller payment 03:47:37, change Insert 03:48:08, exit 03:50:42 UTC. The exit waited 154 seconds for a block, which is the chain, not the code.

Costs of the tUSDM run for each party: the depositor paid 0.175 ADA of fee plus 1.392 ADA attached to the deposit, which the crank kept; the agent paid 1 tUSDM to the relayer and nothing in ADA for the payment; the relayer spent 0.700 ADA of fee plus the 2 ADA it attached, and earned 1 tUSDM; the seller received 2 tUSDM plus 1.832 ADA; the exit cost the user 0.649 ADA of fee plus 1.056 ADA attached to the exit output, which stays in the user’s wallet.

The zx402 pool

On 2026-10-07 the five protocol byte strings took the name zx402 (Spec 1.0.7). Labels, contexts, note secrets and role keys changed with them, so a new tUSDM pool was deployed at 07:08 UTC from the same proving keys. The tUSDM pool d433ba1c… from earlier that day is retired; its record is in deployments/retired/.

The pool ID is 60279ebfb8db22bbe0cb2a1b7a61702ab36ade074a3866ac836df3ed. The deploy cost 245.04 ADA, of which 160 ADA funded the roles.

The demo ran once against the zx402 pool, at 07:15 UTC on 2026-10-07, with the same steps as the tUSDM run: a deposit of 10 tUSDM, a payment of 2 tUSDM to the stock x402 seller, and a public exit of the 7 tUSDM change. It ended with HTTP 200 and the weather body after 350.9 seconds.

The sizes equal the tUSDM run’s, because the renamed strings keep their byte lengths. The execution units differ by less than one percent, which is the usual variation between runs with different inputs.

Block times: deposit 07:15:15, Settle 07:18:26, seller payment 07:18:48, exit 07:20:32 UTC. The note waited 196 seconds to become spendable because the deposit’s block, the Insert and the ASP update landed in three blocks 110 seconds apart, which is the chain, not the code.

The staged demo: a pool funded earlier, one payment

On 2026-10-07 at 07:54 UTC the demo ran with --reuse --no-exit on the zx402 pool: no deposit, one private payment from a note already in the pool, and the change left inside for the next run. This is the shape of the owner’s demo. The seller answered HTTP 200 after 96.6 seconds; the whole run took 99.7 seconds. The demo printed the explorer links, which the README repeats with screenshots from cexplorer (docs/evidence/).

The sizes and fees are the explorer’s rounded figures; the execution units of a Settle are the same as in the runs above, because the validator and the circuit did not change.

Three earlier attempts of the same staged run failed at leg 2 with “Blockfrost submitTx failed” from the seller’s facilitator, while every run with a fresh deposit had worked. The cause was in our builder: the Conway set tag on the inputs of leg 2 was written only when a Mesh transaction builder had been constructed earlier in the same process, which a fresh-deposit run does and a --reuse run does not. The stock facilitator re-encodes every transaction with the tag before it submits, so the body hash changed and the node rejected the signature. Resubmitting the original bytes went through, which is how the cause was found. The builder now sets the tag itself (regression test TX-09). Those attempts left 2 tUSDM plus 2 ADA at each of three one-time addresses (indexes 1, 2 and 3), recoverable with the SDK’s recoverOneTimeFunds; the one-time funds of index 3 were spent by the resubmission, which paid the seller once more.

A Masumi agent paid from the pool

On 2026-10-07 at 07:22 UTC the pool paid a Masumi agent on Preprod: “Expose: Web Single Answer” (registry asset 7e8bdaf2…dbc77, API https://staging.kodosumi.io/sumi/web_single_answer_cc), priced at 0.01 tUSDM in the pool’s unit. Masumi agents are paid through a Masumi payment service node, which locks the price in Masumi’s escrow contract from its own purchasing wallet. The command npm run masumi -w ops funded that wallet from the pool in private, started the job, created the purchase on a local Masumi node (payment source V1, the version every agent in the Preprod registry uses), and read the answer.

The run was split in two by a surprise: the agent’s start_job answer carries no amounts field, which the first version of the command required. The first run deposited, paid the purchasing wallet (134 seconds to a spendable note, 188 seconds to the funded wallet) and stopped at the job start. The fixed command found the wallet already funded, started job 6ac5f4b82173c6fa74f8fe68 after 15 seconds and created the purchase after 18 seconds. The Masumi node batches escrow locks every four minutes, so the lock entered the chain after 372 seconds; the agent answered 1 second later, with a one-sentence answer and three cited sources.

The agent’s seller never saw the pool. The purchasing wallet received its tUSDM from a Settle output, which looks like any other payout, and the escrow lock is a plain Masumi transaction from that wallet.

Two clean Masumi purchases, one of them end to end

After the fixes above, the command ran twice more against the same agent on 2026-10-07. The first run (09:24 UTC) paid from a note already in the pool: Settle 0d90e8a6…, escrow lock c078b060… after 302 seconds, job 6ac61036… completed. The second run (09:31 UTC) started with --deposit, so one command shows the whole trail: deposit, private payment, escrow lock, answer. It is Demo 2 in the README, with the terminal log in docs/evidence/masumi-demo-2026-10-07.log and cexplorer screenshots in docs/evidence/masumi-*.png.

The Settle spent one of the pool’s notes; the chain cannot tell which, and the fresh deposit of this run is one of several candidates. The agent’s answer, one sentence with three cited sources, came back through the Masumi job status.

Admin transactions on Preprod

Run on 2026-10-06 on the rehearsal pool with ops/src/admin.ts.

The sweep returned 73.55015 ADA to the operator. Its fee is higher than a plain payment because the ledger charges for the bytes of every reference script on a spent input.

4. End-to-end timings

The time runs from the request to the seller until the seller answers HTTP 200. It covers the proof, the settlement by the relayer, one confirmation of the first leg, the second leg, and its check and one confirmation by the stock facilitator.

The demo on Preprod, step by step

The four runs of the demo command from section 3. Times are in seconds.

Waiting for blocks dominates every step. The longest single wait, 75 seconds for the exit of the second run, was one slow block.

The third run was slow up to the spendable note. Two things in the node of that run caused it. The crank repeated an idle step only after 60 seconds, so it submitted the Insert 98 seconds after the block of the deposit. The indexer read each new block once. Right after the block of the association update, the provider still served the old association output. The next block came 67 seconds later, so the note became spendable 82 seconds after the block of the update. The final code repeats an idle step after 20 seconds. While the pool is active, its indexer reads each new block a second time 5 seconds later. In the fourth run the crank submitted the Insert 33 seconds after the block of the deposit. The note became spendable 13 seconds after the block of the association update.

In the first and second run the payment to the seller entered the second block after the Settle. In the third and fourth run it entered the next block. Four runs are too few to say whether the code or the block times made that difference.

Provider requests of the node

In the third and fourth run the node counted its HTTP requests to Blockfrost. The pool had about 20 transactions.

A round comes every 10 seconds, and Preprod makes about three blocks a minute. That gives 27 requests a minute for a node that submits nothing, or about 1,600 an hour. The seven measured minutes average 19 requests, or about 1,100 an hour, because they had fewer blocks. For two minutes after a change, the second read of each new block adds 7 requests per block. A read of the history costs one more request for every 100 transactions at the pool address and at the deposit address. The demo and the seller’s facilitator make their own requests. This count does not include them.

Step timings on Preprod

One sample each, from the pool story in section 3, run step by step on a laptop that was busy with other work. Preprod makes a block about every 20 seconds.

From the block of the deposit to the block of the second stealth leg, 224 seconds passed. That covers the deposit, its insertion, its approval, the private settlement and the payment to the seller, each started by hand after the previous one confirmed. An indexer that starts cold replayed this history of five pool transactions in about 10 seconds.

5. Differences from the Spec estimates

No estimate in SPEC section 10.3 was wrong by more than 20 percent.

Settle and Ragequit use about 10 percent more CPU than estimated, and both stay under a third of the transaction limit. The Spec estimated 1.0 to 1.2 ADA for one private payment in stealth mode, counting a quarter of an Insert. The measured two legs cost 0.849327 ADA. A quarter of the Insert of one note adds 0.16 ADA, which gives 1.01 ADA. When a change note is inserted alone, the whole Insert of 0.638118 ADA belongs to that payment, which gives 1.49 ADA.

6. Contract building blocks

Measured in Aiken 1.1.24 unit tests on 2026-10-06. Each number includes the small cost of the test itself.

Whole runs of the pool validator, measured in Aiken tests with real proofs. The limit for one transaction is 10,000,000,000 CPU steps.

A skipped zero input saves 130,679,623 CPU. So one proof check costs about 1.90B CPU plus 0.131B for each non-zero public input. That is close to the model in SPEC 10.2 (1.87B plus 0.13B).

7. Off-chain library

Measured on an Apple M2 Max with Node 24.10.0 on 2026-10-06.

8. Development key setup

Measured on an Apple M2 Max with Node 24.10.0 and snarkjs 0.7.6 on 2026-10-06. The machine ran other builds at the same time, so read the long steps as upper bounds.

Two forced builds gave the same R1CS files, so the circuit build is reproducible.

The keys are not reproducible. snarkjs mixes 64 random bytes from the operating system into every contribution, even when the caller passes a fixed text. So each machine gets its own development keys, and proof fixtures must carry the verification key they were made with.