Watch the boundary hold.
Three requests from an autonomous agent. One is routine, one is far over the line, and one needs the owner. The frame they are judged against was signed once, by a person, and the agent cannot argue with it.
This page is a re-enactment of the decision path, scripted from the product's real rules. It calls nothing and signs nothing. The measured execution further down is the real thing.
The frame
- max per transaction
- $50
- daily cap
- $200
- confirmation above
- $25
- allowed tokens
- USDC, WETH
- allowed recipients
- owner-signed list
- rate
- 10 per minute
The owner signed this frame once, with their own key. Every request below is judged against it.
These are Zyndr's conservative defaults for a new agent. An owner can change them, and changing them is itself an owner-signed action.
The request
A payment the owner already allowed
The ordinary case, and the one that has to feel invisible. The agent pays a bill it is allowed to pay, and nobody is interrupted.
The agent's own schedule
Pay this week's inference bill.
- action
- LLM_PAYMENT
- amount
- 12.00 USDC
- to
- 0x7c19…4f02 on the owner's list
What happens next
The agent proposes an intent
passedThe agent describes what it wants in structured fields. It holds no key and it signs nothing.
Off-chain precheck
Owner confirmation
Exact-operation simulation
Broadcast, then on-chain enforcement
Signed receipt
Watching the request travel toward the boundary.
Evaluating the request.
Two layers
Only one of them is the authority.
Both layers can stop an action. The difference is what happens when one of them is wrong, unavailable, or lied to.
Simulation
can reject, never authorizesA mandatory gate before broadcast. Zyndr rehearses the exact operation it is about to send, and a revert, an unreachable simulator or a missing result all stop the broadcast. It can reject an action. It never authorizes one.
PolicyModule
the on-chain authorityThe owner's boundary, enforced on-chain. The contract re-checks the action inside the execution and does not treat the simulation result as authority. This is the layer that decides whether funds may move.
Notice where the verdicts appear in the run above. A rejection can come from the off-chain layer, because rejecting is something that layer is allowed to do. The policy engine can also allow an intent to proceed, and that word deserves care: it is permission to continue toward execution, not authority to move funds. The intent waits, it is re-checked before anything is sent, and the exact operation still has to pass simulation and the contract's own check. The demo shows its final approval at the on-chain stage because that is where the authority to move funds sits.
Not a re-enactment
One real execution, including the part that did not verify.
Everything above is scripted. What follows was measured on Base Sepolia during the gate for the change that made simulation mandatory. It was a smart account's first operation: the account did not exist beforehand, and the same operation created it and executed the transfer together.
Measured on chain
Base Sepolia · 84532- agent
- Agent #10
- smart account
- 0x1348edc1E91eDdaA38C1e8614aEB263C09B2D4f5
- action
- 0.001 USDC transfer
- user operation
- 0xed9c6d3186e9ad7d76d05292367c9ca01178f8f9347950f3cbdafca6614232cd
- block
- 46,517,020
- receipt verdict
- ALLOW
What was observed
- The smart account had no code before this operation.
- The operation carried a paymaster and deployed the account atomically.
- AccountDeployed was emitted.
- UserOperationEvent reported success.
- The account had 61 bytes of code afterwards.
- Exactly 0.001 USDC moved, and nothing else did.
- The signed receipt for the decision records the verdict ALLOW.
Receipt verification
INCOMPLETE7 checks passed. 1 was skipped. Overall: INCOMPLETE.
The skipped check is allow_resim. The skipped check re-runs the on-chain decision at the block the receipt names. At that block the smart account did not exist yet, because this same operation is what created it. The check cannot run, so the verifier skips it rather than guessing, and a skipped load-bearing check can never produce a VALID result.
INCOMPLETE is shown here exactly as the verifier reported it. A verifier that upgraded an unrunnable check into a pass would be worth nothing.
What this run is not
- One execution on a public testnet, not a benchmark and not a guarantee.
- No simulation gas figure or simulation block is published for this run, so none is shown.
- The receipt does not commit to the simulation result. That field still carries a placeholder.
Honest limits
What this page is not claiming.
A demo that only shows the good outcome teaches nothing. These limits are recorded in the repository and repeated here for the same reason they exist there.
This page is a re-enactment. It calls nothing, signs nothing and moves nothing.
Simulation is mandatory before broadcast and it is fail-closed, but it is not the on-chain enforcement authority. PolicyModule is.
The signed receipt does not yet cryptographically commit to the simulation result. That field carries a placeholder today, and the work to make it a real commitment is still open.
Your owner key controls your agent's policy. Zyndr bounds what a tricked agent or the day-to-day automation key can do on-chain; it does not remove the risk of losing your own master key.
Everything Zyndr runs today is on the Base Sepolia testnet. No mainnet deployment exists.
Now do it with a real agent.
Create an agent, sign its boundary once, and watch an out-of-policy action get stopped at the contract. Base Sepolia testnet, no real funds.