The current entry is ETHGlobal Tokyo 2026 (9/25–27, Continuity track, applying for the ENS and Uniswap Foundation prizes): an agent earns a record it cannot write itself, and that record is its pass to a Uniswap v4 pool. None of that submission exists yet — it is built during the event.
What it will be, and the boundary between what already existed and what is built: the disclosure · the specification · what was measured before building it.
A Tempo payment that settles only when a Solana action can be reproducibly proven.
Every number below is read by your browser, from Tempo, when this page loads. Nothing here is a screenshot and nothing is typed into the page by hand.
refundAfterDeadline is
not demonstrated and will not be: time cannot be warped on a public chain, and the
judging window is shorter than the deadline. The refund you can see in section 5 is a
different thing — it is driven by a proof and is immediate. And the proof establishes
that the declared prestate and execution produced the committed result; it does not
establish that those inputs came from Solana mainnet.
Why Tempo?
Tempo is not just another EVM deployment. It has no native gas token: fees are paid in a USD-denominated TIP-20. So the escrow holds a stablecoin, and the fee that releases it is paid in that same stablecoin — the payment and the cost of deciding the payment are one unit. On Arc that sentence is false (USDC is the 18-decimal native gas token and the escrow holds a separate 6-decimal ERC-20 face of it), and on a chain with a separate gas asset it is false by construction.
Section 4 below reads that off real receipts rather than asserting it. What Tempo also adds is a limit: a TIP-20 issuer can pause the token or a TIP-403 policy can refuse a recipient, and a pause stops a proof-authorised release and the thirty-day refund. Reckn removes a protocol-level judge; it does not erase issuer policy. Side by side with Arc: chain-fit.md.
1. Which chain this is — and the URL that is not it
… asking both endpoints…
| the testnet | … |
| also published | … |
Two URLs are published as “the Tempo RPC”. They answer on different chains. Every constant around the wrong one still looks right — right scheme, right domain, right shape — which is how a deployment lands on the wrong network with nothing visibly out of place. Your browser just asked both.
2. Groth16 is possible here
… calling the pairing precompiles…
| precompile | input | returned |
|---|
Reckn's verdict verifier is an SP1 Groth16 verifier, and Groth16
on an EVM chain is BN254 arithmetic in precompiles 0x06, 0x07 and
0x08. If they were missing or repriced, this direction would not exist. This
is the single question that could have ended it, and it is answered by
eth_call — no key, no gas, no deployment.
What this does not show: that a real proof verifies here, or that it fits the fee model. Present precompiles are necessary, not sufficient.
3. There is no gas token — the fee is a stablecoin
… reading two balances…
| an address | … |
| another | … |
eth_getBalance returns the same enormous constant for any
address, because there is no native balance to report. Anything that shows funding by
reading a native balance on Tempo is showing a constant.
… reading the fee token…
| address | … |
| name / symbol | … |
| decimals | … |
4. Read out of real receipts: what actually paid
… scanning recent blocks…
| transaction | type | fee token | gas used |
|---|
Every receipt carries feeToken and feePayer —
including for a plain type 0x2 transaction. So the evidence that a settlement
was paid for in a stablecoin is emitted by the chain itself, and needs no custom
transaction type to produce.
5. The settlements — read from the chain, in your browser
| Escrow | … |
| Verifier | … |
| SP1 Groth16 | … |
| Escrow codehash | … |
… reading the deals…
| deal | the proof said | the TIP-20 went | fee paid in | state |
|---|
Nothing in this table was passed to the page. The generator hands over deal
ids and transaction hashes; your browser calls deals() on the escrow and reads
the settlement receipts, and works out the rest. The third row has no transaction
because a real proof of a different execution was rejected before it reached a block — so
the money is still in the escrow, where you can see it.
6. What crosses, and what does not
| Crosses | A Groth16 proof of a re-executed Solana computation. |
| Does not cross | The stablecoin. It is on Tempo before and after. |
| Never happens | Tempo running a Solana VM. There is no bridge and no light client here. |
7. The limit this chain adds
The escrow names no privileged address. On Tempo, the token does.
A TIP-20 issuer can pause the token, and a TIP-403 policy can refuse a
recipient. A pause stops a payout a valid proof authorised — and it stops the 30-day
refund too, so there is a state in which both exits are closed by a third party. That is
strictly further than Arc's blacklist reaches, where the timeout stayed open. It is
disclosed, tested (TEMPO07, TEMPO08), and not mitigated.
Check it without this page
…
Generated from zk-verdict/contracts/tempo.json, this page's
template and its generator — those three files digest to
…. No constant on this page was typed into it: the
generator reads the record, and the record says how each value was obtained.