Product

An authorization boundary,not an RPCwrapper.

An agent may propose an action. Ravelin Wall evaluates it against explicit policies, state and spending limits before the protected account authorizes execution.

Components01

01Specified · not deployed

Authorization engine

Deterministic policy evaluation for transactions, UserOperations, spending, recipients, contracts and repeated actions.

02Specified · not deployed

Protected signing service

Policy-bound signing inside a TEE. The parent host cannot request a signature that skips evaluation.

03Specified · not deployed

On-chain account enforcement

Smart-account validation that rejects operations without a valid Ravelin authorization.

04Specified · not deployed

Developer SDK

Typed clients for TypeScript (viem first, then ethers) and Python, with no security logic of their own.

05Specified · not deployed

Security control plane

Policy management, human approvals, API credentials, emergency stops and attestation verification, enforced server-side.

06Available · local simulation

Developer platform

This site and its documentation, the policy workbench, and the console as a browser simulation workspace.

Rule types · v102

Capital and budget: Per-transaction maximum, rolling hourly and daily spend, gas ceiling, per-token allocation, maximum exposure.
Rate limits and loops: Repeated calldata, repeated intent fingerprints, requests per interval, per-agent quotas, cooldowns.
Contracts and methods: Allowed chains, targets, code assumptions, function selectors, recipients, token allowlists.
Human authorization: Value thresholds, new recipients, sensitive methods, overrides, independent signatures.
Emergency controls: Pause an agent, revoke a key, disable a policy, pause an account, stop all authorization.

Schema 1.0 covers per-transaction, gas and hourly limits, allowlists, denylists, cooldowns and approval thresholds. See the policy reference.

Not in the first release03

Replacing the EVM, the Robinhood Chain sequencer or Ethereum settlement.
Protecting transactions that bypass the configured smart account or protected signing path.
Claiming that a TEE prevents all compromise, side channels or supply-chain attacks.
Building an AI model, agent framework, exchange or trading strategy.
Storing private prompts, or requiring an LLM to disclose its reasoning.