Security
3 min read
Overview
RAC is not designed as a fully open execution environment.
It uses a deliberately narrower operating model: approved users, approved operators, and a transaction pipeline that validates state changes before they ever reach the contracts.
That matters because many onchain exploits depend on one thing above all else:
getting a harmful transaction to execute before anyone meaningfully inspects the resulting state transition.
RAC is built to make that much harder.
Design Principle
The security model is based on a simple idea:
reduce the attack surface first, then validate aggressively before execution.
Rather than exposing every critical workflow to anonymous participation, RAC keeps sensitive paths controlled and permissioned. And rather than letting state-changing transactions flow straight through to contracts, RAC routes them through a simulation and review layer first.
This is not security through one mechanism. It is security through structure.
Closed-Access Participation
RAC uses a permissioned participation model for the most sensitive parts of the system.
In practice, that means:
- the user base is whitelisted rather than fully open
- keepers are approved operators, not an open public network
- solvers are approved operators, not a public free-for-all
- critical contract-touching actions do not sit open to arbitrary actors
This materially changes the threat model.
A large amount of DeFi risk comes from open admission: anyone can interact, anyone can probe edges, anyone can race into a weakness the moment they find it.
RAC intentionally narrows that surface.
Pre-Execution Validation
Every keeper-routed transaction that touches the contracts goes through a validation pipeline before execution.
At a high level, the flow is:
- prepare the intended transaction
- simulate the contract call
- inspect the resulting state transition
- run an AI validation pass on the simulated outcome
- execute only if the transaction passes
This means RAC is not relying on blind transaction submission for sensitive actions.
The system gets a chance to inspect the outcome before state changes are committed onchain.
Simulation-First Execution
RAC uses a simulation-first model for contract-touching execution.
The keeper stack runs a full simulation before signing and broadcasting the transaction. Internally, that means previewing what the transaction would do to balances, state transitions, and downstream effects before execution is allowed to proceed.
The important product-level point is simple:
RAC evaluates the post-transaction world before accepting the transaction.
That is a meaningful security property.
A large class of blockchain exploits rely on a single malicious or malformed transaction reaching execution unchecked. By inserting simulation ahead of execution, RAC raises the bar materially against exactly that pattern.
AI Validation Layer
Simulation alone is useful, but RAC adds another layer on top: AI review.
The simulated transaction output is evaluated before signing. If the result appears inconsistent, abnormal, or unsafe, the transaction can be rejected before it touches the contracts.
This is especially useful because not every bad transaction is a simple revert.
Some of the most damaging failures in crypto are transactions that technically succeed, but produce a state transition no operator should have accepted.
The AI layer exists to help catch that category of problem.
Why This Matters
Security failures in crypto often compress into a single moment.
A transaction gets through. State changes. Funds move. The damage is done.
RAC’s model is designed to interrupt that sequence.
By combining:
- closed participation
- approved operators
- simulation before execution
- AI review before signing
the protocol is designed to reduce the probability that an obviously dangerous transaction reaches final execution.
This would not eliminate every conceivable risk. But it is a strong defense against exploit patterns that depend on immediate, unchecked execution.
What This Does Not Mean
This model does not mean RAC is risk-free.
It does not mean software bugs are impossible. It does not mean every edge case can be predicted in advance. It does not mean human operators can never make mistakes.
What it does mean is that RAC is designed with a narrower and more controlled operating surface than a typical fully open onchain system.
That is a meaningful difference.
Summary
RAC’s security model is built around two core ideas:
- keep sensitive participation closed and approved
- validate transactions before they execute
The result is a protocol that is intentionally harder to exploit through the most common crypto pattern: a single malicious transaction reaching the contracts unchecked.
RAC is not trying to be maximally open at every layer. It is trying to be robust.