A Zap cannot do anything it was not signed to do.

Current release map

Status belongs to a contract lineage or product path, not to the repository as a whole. Live, deployed candidate, and source-ready are separate states.

Three authorities, kept apart

Quickstart

The product lives at /zap in five surfaces: Start chooses an outcome, Compose builds the route and policy, Zap now creates and executes live v1.1 Zaps, Automate creates live v3/v3.1 recurring or price-triggered Zaps, and Connect prepares an executor address for terms the owner later signs. The builder compiles a design and names every guard the selected contract does not bind. A deployed route carries its amount, slippage, execution gas, and gas-price cap into Zap now. Automatable designs also carry cadence, Zap count, trigger terms, and executor access into Automate. The v3.2 stacking path remains a deployed candidate; anything else saves as a design and cannot deploy today. Simulation never broadcasts a transaction or asks for wallet authority.

A copied ?d= share link carries only the designed chain into Compose. The builder treats that payload as untrusted: it bounds its size and node count, keeps only recognized blocks and valid parameter values, then recompiles what survives against the current catalog. The link grants no wallet authority. Design mode never prompts for wallet access, approval, funding, a signature, or a transaction. A supported live route still requires the receiver to review the selected lineage's enforced bounds and confirm the required wallet signature or transaction; anything outside the supported routes remains a design-only blueprint.

curl -X POST https://www.0xzaps.com/api/policies/simulate \
  -H "content-type: application/json" \
  -d '{
  "routeId": "robinhood-v4-weth-zaps",
  "owner": "0x0000000000000000000000000000000000000001",
  "amount": "0.01",
  "slippageBps": 150
}'

Execution policy composer

The block catalog now has three live execution-policy controls. The builder can insert every missing control as one stack, in one history checkpoint. One Undo restores the chain that existed before the stack was added. Each card stays independently editable after insertion.

Wallet balance
  → Execution gas limit   3,000,000 gas
  → Gas price cap         10 gwei
  → Executor access       Anyone | Owner only
  → Swap
  → Send

Zap now handoff:
  maxGas=3000000&maxFeeGwei=10

Automate handoff:
  maxGas=3000000&maxFeeGwei=10&executor=owner

Gas limit and gas price cap are signed in v1.1 one-shot intents and standing intents. Owner-only executor access is live in v3/v3.1; v3.2 uses the same field but remains a deployed candidate. The v1.1 one-shot Zap has no submitter restriction, so the builder leaves that field out of its Zap now handoff and shows the limitation before the user proceeds. Invalid or out-of-range handoff values fail closed instead of falling back silently.

Policy schema

The signed object is small on purpose. Any field that could widen what an execution may do is in the policy the owner reads before signing. A field that is not in the policy is not enforced by the contract.

Simulation API

The chain-exact endpoint pins every required read and route quote to one canonical Robinhood Chain block. It returns the block identity, live adapter and token allowlists, runtime code hashes, a seeded-vault proof when the route requires one, the block-pinned quote and minimum output, the Solidity-exact policy hash, an unsigned EIP-712 draft, and an ephemeral factory eth_call. Stress-quote failures stay explicit and produce a warning instead of synthetic output. The endpoint never signs or broadcasts. In production it fails closed unless both the exact-policy API and durable-quota gates are active; an unavailable response is not a simulated pass.

type ExactPolicyArtifact = {
  status: "pass" | "warn"
  mode: "chain-exact"
  chain: {
    chainId: 4663
    blockNumber: string
    blockHash: `0x${string}`
    rpcStatus: "verified"
  }
  allowlists: { adapterAllowed: true; tokens: Array<{ allowed: true }> }
  runtimeCode: { factory: object; implementation: object; adapters: object[] }
  quote: { amountIn: string; amountOut: string; minOut: string; blockNumber: string }
  compiled: {
    policyHash: `0x${string}`
    predictedZap: `0x${string}`
    unsignedEip712: object
  }
  ethCall: { method: "eth_call"; broadcast: false }
  stressCases: Array<{ status: "quoted" | "rpc-failure" }>
  authority: { signed: false; broadcast: false }
}

Hookr pools: buy, zap in, zap out, migrate

Every token Hookr graduates trades in a hooked, dynamic-fee Uniswap v4 pool: the V5 launchpad’s HOOKR-quoted pools share one hook, Modular V2’s ETH-quoted markets share one kernel, and Modular V3 gives every market its own hook instance recorded by Hookr’s coordinator. OpenZaps reaches all of them through one HookedRangeVault per pool (a full-range position wrapped as an ERC-20 share, deployed permissionlessly by HookedRangeVaultFactory, which admits a V3 instance from the coordinator’s own live record), two universal LP adapters that take the vault or the settlement asset as factory-verified step data, and one market swap adapter that buys or sells any coordinator-recorded market by pool id. ETH-quoted markets are presented to the capsule with aeWETH as the quote. A third-party UI needs no contract integration: it links into the signer with a route id and an amount, the signer resolves every address from its own manifest, and the user signs one policy.

GET /api/hookr/routes            // every pool, its route ids, and ready-made links

// Buy a V3 market's token with aeWETH (one step; pool id is the route's bound)
/zap?view=sign&src=build&route=hookr-market-buy-<pool>&amount=0.01&bps=150

// Zap in from HOOKR (one step)
/zap?view=sign&src=build&route=hookr-lp-deposit-krn&amount=10000&bps=150

// Zap out to HOOKR (one step; amount = vault shares)
/zap?view=sign&src=build&route=hookr-lp-withdraw-krn&amount=1&bps=150

// aeWETH -> HOOKR -> pool, or pool A -> HOOKR -> pool B (two steps, one signature):
// the API's "policy" token pins the ordered steps; step 2's amount is frozen at
// signing and becomes step 1's minimum output.
/zap?view=sign&src=build&route=hookr-lp-withdraw-krn&amount=1&policy=<token>

Honest limits: a deposit swaps exactly half the input inside the pool (paying the hook’s dynamic fee), refunds whatever the ratio cannot absorb to the capsule, and reverts while a pool’s anti-snipe guard is still active. Redemption can never be blocked: the vault refuses hooks with removal permissions at construction. The vault and adapters custody real funds and are unaudited; a new launch becomes reachable after one permissionless createVault and one governance allowlisting of its share token.

Policy templates

The cards below are built-in draft starters. The public registry is readable only when configured; wallet-attributed publication and exact-version subscriptions are separate production-gated writes. A subscription is convenience metadata, not execution authority, reputation, or permission to follow an unreviewed latest version.

Automation & the executor economy (v3 / v3.1)

The v3 Zap adds two standing execution types to the one-shot policy. Both are owner-signed once and condition-gated by the contract, so an eligible executor can submit a run the Zap owes, and the chain rejects every run it does not.

v3.2 adds an owner-signed post-fee output slice that stacks 0xZAPS, two spot-derived floors, and a one-way permanent policy halt. Its contracts are deployed, and the lineage remains a candidate until its production creation, execution, halt, and evidence canaries pass.

Fees. Each automated Zap pays 1% of its measured output at settlement: 80% to the executor that submitted it, 20% to the protocol lottery pot, converted to 0xZAPS through the pinned bounded adapter by a later, permissionless keeper call. Floors are enforced netof the fee — both the absolute minimum-out a price trigger signs and the per-run floor a recurring Zap derives from spot. Every fee contribution credits lottery tickets to the Zap's owner; the pot pays prizes only in 0xZAPS and only to ticket holders — there is no owner drain. Winner selection is a deferred, governance-gated decision until a randomness ADR lands.

Creation fee. Every Zap created by the current app — one-shot, recurring, or triggered — separately pays exactly 0.00001 ETH. The fee gateway calls the existing lineage factory, wraps the fee to aeWETH, and converts it through the pinned aeWETH → 0xZAPS adapter in the same transaction. The wallet reviews both the fixed fee and a fresh minimum 0xZAPS output before signing; if factory creation or conversion misses that floor, the whole transaction reverts. The old immutable factories remain callable directly, so this is an app-enforced creation path rather than a retroactive change to already-deployed factory bytecode.

Build one in Compose, then review it in Automate. The signed intent exports as a JSON file an eligible executor can serve; the reference executor daemon lives in executor/ in the repository. The v3 and v3.1 contracts are live on Robinhood Chain.

Connecting an agent

An agent is connected to a Zap when you sign a standing intent naming that agent’s address in the intent’s executor field. The capsule reverts ExecutorMismatchfor anyone else. There is no credential to issue, store, or steal — the connection is one field of your own signature, and nothing off-chain is trusted to enforce it.

That bounds the blast radius exactly. A fully compromised agent can submit a run the capsule already owes, or refuse to submit one. It cannot change the recipient, amount, cadence, or output floor; cannot run early, twice, or past the end; and cannot create, fund, or drain a capsule. Leaving the executor unset (0x0) keeps the authorization open to any submitter, which maximises liveness; pinning one address trades that for exclusivity, and a pinned agent going offline stalls the series until you submit it yourself or sign new terms.

The read-only Agent Kit can discover capsules and request exact policy simulations. It holds no key and reads public chain data; it has no credential that could be mistaken for execution authority. Its scoped npm release is live; point your client at it, ask the agent for its public address, then pin that address in Connect.

{
  "mcpServers": {
    "openzaps": {
      "command": "npx",
      "args": [
        "-y",
        "@openzaps/mcp@0.1.0"
      ]
    }
  }
}

Pinning is public: the executor address is inside the signed intent and in the chain’s logs, so anyone can see which agent runs your Zap. To revoke, stop the agent (the series stalls, costing no transaction), invalidate the authorization id onchain, or sign fresh terms under a new series id.

Execution lifecycle

SDK surface

The published @openzaps/sdk@0.1.0 source lives in packages/sdk. It compiles the Solidity policy tuple and prepares unsigned EIP-712 data; its client exposes the exact simulation endpoint and has no signing or broadcast method.

import { OpenZapsClient } from "@openzaps/sdk"

const openzaps = new OpenZapsClient()
const artifact = await openzaps.simulatePolicy({
  routeId: "robinhood-v4-weth-zaps",
  owner: "0xYourAddress",
  amount: "0.01",
  slippageBps: 150,
})

// Live allowlists + code hashes + quote + policy hash,
// unsigned EIP-712 draft + eth_call. Never a transaction.
if (artifact.status === "warn") reviewStressCases(artifact)

Every chain-dependent field is pinned to one block. An RPC failure stays labelled unavailable; the client never substitutes a fixed token price. What actually executes is the deployed contract, not this surface. Read the verified source before signing anything. 0xZAPS is not required to simulate or inspect a policy.

Security model

A Zap — the immutable policy capsule the factory deploys — holds funds and accepts owner-signed intents that rehash to the policy frozen at creation. The adapter, the spender, the recipient, the input token, and the exact amount are fixed at that moment. An executor picks the moment and nothing else.

Bounded aeWETH ↔ 0xZAPS creation is open on Robinhood Chain, and the funds a Zap holds are real. Production use still needs formal verification, adapter governance, and a monitored launch path. Onchain actions are irreversible: once an execution lands, nothing here can undo it. Owners retain lineage-specific nonce or series invalidation and tracked-asset recovery controls; the v3.2 candidate also exposes a one-way permanent policy halt. Deposit only what you can afford to lose.

User / Safe
  -> OpenZapFactory
  -> OpenZap clone with frozen policy
  -> allowlisted adapter
  -> recipient-bound postcondition

Agent / executor:
  discover -> simulate -> eligible submission -> public evidence
  no wallet key or signing authority
  no arbitrary calldata or automatic revoke right

Controls

Threat model

Production gates

None of the following has completed. Each one is a precondition for calling the contracts production-cleared. Until they have, the only thing standing behind a failure in the contract, the interface, the relayer path, or the adapter registry is the owner's exit.