How it works
From intent to a landed trade, in one layer.
An agent can move money. It can’t tell if it should. Metera takes the action through six steps, and the first two are live today.
The path
Today Metera verifies and your agent signs. The rest of the path is what the waitlist opens.
- 01Live
Declare
Your agent hands Metera the transaction it wants to send, the intent behind it (the pool, the output token, exact in or exact out, the minimum it accepts) and the policy it must meet: maximum price impact, risk ceiling, allowed tokens and programs.
- 02Live
Verify
Metera reads the exact bytes that would be signed, simulates them on independent nodes at the same slot, and checks the token, the quote, the pool and every instruction against the intent and the policy. One verdict comes back: allow, allow with caveat, or refuse, with the reason for each.
- 03Waitlist
Sign
What passed is signed from your own vault, a Turnkey enclave, under the policy you set. The key never leaves the enclave, and Metera never holds it.
- 04Waitlist
Execute
The signed transaction is routed through Jito, Astrolane or Temporal’s Nozomi, with the tip checked and sandwich protection applied.
- 05Waitlist
Reconcile
Every send is followed to an end state: landed, expired, or do not resend. A trade is never paid for twice.
- 06Waitlist
Earn
When a trade produces a rebate, the arbitrage a bot would have taken comes back to you. It depends on the trade, so it is never promised.
Inside the verification
The live half, in four passes over the exact transaction. Any one of them can refuse, and a refusal is never charged.
The transaction itself
It decodes, resolves its lookup tables and simulates on two nodes. Nodes that disagree, a blockhash that cannot be confirmed, a fee payer that cannot pay: refused.
The accounts and the token
Every account belongs to the program it claims to. Token-2022 extensions that can freeze, pause or hook a transfer are read, not assumed.
What the swap really does
The pool, the direction, the output token and the minimum out in the bytes must match what the agent declared. A swapped mint or a lower minimum is refused.
What should never be there
Approvals, authority changes, mints, burns, closes that send rent elsewhere, program upgrades: none of them belong in a swap, and each is refused on sight.
Two reads, one slot
A single read is a guess. Metera reads from independently operated nodes pinned to the same slot. Agreement is a fact; disagreement returns nothing, because averaging two reads taken a slot apart is a prettier guess, not consensus.
- single_source
One read that passed its checks, and nothing confirmed it. Labelled as exactly that.
- consensus
Two independently operated nodes agreed at the same slot. Disagreement returns nothing.
- anchored
Tied to an on-chain or oracle reference that does not depend on Metera.
What the verdict does not cover
Every verdict ships with its own scope, and the limits are published, not buried. Landing and MEV are what the execution half is built for.
- MEV and sandwich risk between the check and the moment it lands
- Whether the transaction lands at all
- Jupiter-routed transactions, and Transaction v1
- Market risk: a clean trade can still be a bad one
