When we started building Ava, we thought the hardest part would be teaching a model to reason about crypto. That turned out to be only one part of the problem.
A user can type, “Swap 500 USDC to ETH,” and the model can understand the request immediately. But understanding is not execution. Ava still has to check the wallet, verify the balance, enforce the spending limit, inspect the transaction, decide whether a signature is required and confirm what actually happened onchain.
Security questions create a different problem. Ava needs research the model may never have seen. Wallet questions need live data that no training set can provide. And none of those systems can be allowed to quietly disagree when someone’s money is involved.
That is what makes building a production agent hard: the model may do the reasoning, but the product still has to know, verify and enforce.
We are tackling that challenge by building Ava across four layers: the model, product logic, knowledge and live state. The model gets most of the attention. It is also the layer we are deliberately specializing last.
1. The model is not the product
The architecture that emerged has four distinct jobs:
Those layers cooperate, but they are not interchangeable. Each answers a different question:
- Model: What does this situation mean?
- Product logic: What must happen, and what is Ava allowed to do?
- Knowledge: What should Ava read before deciding?
- Live state: What is true right now?
The architecture gets safer and easier to improve once each kind of intelligence has a home.
Pull-quote candidate: "The model is not the agent. It is one reasoning layer inside a product that also has to know, verify and enforce."
2. Product logic handles what must happen
Return to the swap request. The model can recognize the intent, but it should not decide whether the request is permitted or whether the transaction succeeded.
User: "Swap 500 USDC to ETH"
│
▼
Understand intent
│
▼
Is a wallet connected?
│
▼
Does it have enough USDC?
│
▼
Manual or Auto mode?
│
▼
Is it within the spending limit?
│
▼
Fetch quote
│
▼
Run security checks
│
▼
Prepare / executeIf an Auto-mode wallet has a $1,000 spending limit, Ava cannot remember that rule only when the model happens to reason correctly. The product has to enforce it every time:
if amount > spendingLimit:
rejectThe same is true for expired permissions, insufficient balances, required signatures and transaction confirmation. These are product invariants. They belong in deterministic code, where we can inspect, test and change them.
Our rule is simple:
If getting something wrong can violate a user constraint or contradict reality, enforce it outside the model.
Training may make a model understand a spending limit more often. It does not turn probabilistic understanding into enforcement.
3. Knowledge handles what changes
Now take a different question:
User: "Why is this approval dangerous?"
The base model may know how Ethereum approvals work. Ava may also need an audit published yesterday, a new exploit report, protocol documentation, our latest security research or a newly discovered EIP-7702 attack pattern.
That knowledge changes faster than a model can be trained and deployed. We keep it outside the model and retrieve it when the question requires it. That approach has a name: retrieval-augmented generation, or RAG. The question triggers a search, and whatever it finds is handed to the model along with the question.
Security documents
│
▼
Chunk / index
│
▼
Embedding model
│
▼
Knowledge store
│
│ search
▼
Relevant passages
│
▼
Model
│
▼
AnswerRAG does not teach the model something permanently. It gives the model evidence for this inference. We can add a new incident to the knowledge base tomorrow and make it available to Ava without retraining anything.
That makes RAG useful in crypto, where the facts can change between two model releases. It also makes the source inspectable: we can see what Ava retrieved and whether the evidence supports the answer.
But RAG is not a substitute for live state. If someone asks for their current Aave health factor, Ava should query Aave or the chain—not retrieve an article about how health factors work.
Ava
│
┌───────────┼───────────┐
▼ ▼ ▼
RAG Onchain Tools
state
│ │ │
audits RPC Alchemy
EIPs account code Moralis
incidents balances Aave
research positions DefiLlamaRAG can explain how liquidation works. The chain tells us whether this wallet is close to liquidation now. Mixing those categories creates agents that sound informed while answering the wrong question.
4. The model connects the evidence
Once code has enforced the constraints, RAG has supplied relevant evidence and tools have returned current state, the model has the most interesting job: deciding what the facts mean together.
Suppose Ava sees this wallet:
Wallet
├── 4 unlimited token approvals
├── unknown EIP-7702 account code
├── recent inbound USDC
└── USDC immediately transferred outRetrieving those facts is not the hard part. The hard part is recognizing that the unknown account code changes the meaning of everything else.
Unknown account code
│
▼
Account execution may be compromised
│
▼
Approvals are probably not the primary threat
│
▼
Check whether inbound assets are being swept
│
▼
Do NOT recommend funding the wallet
│
▼
Explain the recovery optionsProduct logic enforces constraints. RAG provides evidence. Live tools establish the current facts. The model connects them into a hypothesis and recommends the next step.
That division is why we are building product logic and knowledge first. Before specializing a model, we need to learn which rules are permanent constraints, which facts will keep changing and which failures reveal a genuine gap in reasoning.
5. Repeated branches are training signals
Early in an agent's development, model failures arrive one case at a time. The fastest responsible fix is often an explicit branch: visible, testable and easy to revise.
Over time, a codebase can start to say the same thing in several different ways:
if unknown7702 && approvals:
prioritize7702()
if unknown7702 && userWasDrained:
checkSweeper()
if unknown7702 && userWantsRecovery:
warnAgainstTopUp()
if unknown7702 && incomingETH:
checkWhetherSwept()
if unknown7702 && delegateChanged:
raiseSecurityFinding()These branches are useful. They keep the product correct while we are still learning the shape of the problem. But five branches may not represent five product rules. They may be five expressions of one security concept:
An unknown EIP-7702 delegation changes the wallet's execution environment. Reason about account code before reasoning about token permissions or recovery actions.
That distinction matters. A branch that enforces a spending limit should remain in code. A branch that repeatedly reminds the model how to interpret a security pattern may be evidence that the model has reached the edge of its natural reasoning.
Pull-quote candidate: "A repeated reasoning branch is not automatically technical debt. It may be the first draft of a training set."
6. Training comes after the specification
Once we have enough verified cases, we can teach a specialized model the concept behind the branches instead of spelling out every variation.
Wallet state
+
Transaction history
+
Security findings
+
Retrieved evidence
+
Expert analysis
+
Correct recommended action
│
▼
Training / distillation
│
▼
Learned security reasoning
│
▼
Novel wallet situation
│
▼
Generalize from learned patternsThis is fundamentally different from RAG:
RAG TRAINING
Question Verified cases
│ │
├────► Knowledge base ▼
│ │ Train
│ retrieve facts │
◄──────────┘ ▼
│ Change model weights
▼ │
Model ▼
│ Future questions
▼
AnswerRAG gives the model things to know for a particular answer. Training changes how the model handles future cases.
Training first would force us to guess at the specification. We would be encoding early assumptions before real users, incidents and corrections had shown us which concepts matter. Product logic and RAG let us build safely while collecting that evidence:
The branches we write today help us discover the future model's curriculum. Each corrected failure can become an eval. Once the same reasoning pattern appears across enough independent cases—and expert review agrees on the right answer—it becomes a candidate for training or distillation.
7. What moves into the model—and what stays out
The goal is not to compress all of Ava's code and knowledge into model weights. It is to move the right abstraction to the right layer.
AVA
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
MODEL PRODUCT LOGIC KNOWLEDGE
│ │ │
reason enforce retrieve
infer constrain reference
plan execute update
│ │ │
└──────────────┼──────────────┘
│
▼
LIVE STATE
│
┌──────────┼──────────┐
▼ ▼ ▼
EVM DeFi Markets
RPC protocols dataOver time, some reasoning workarounds should disappear because the model has learned the concept behind them. Hard constraints should remain in code. The knowledge base should keep changing. Live state should still come from authoritative tools.
That is the architecture we are converging on: keep truth and constraints in code, keep changing knowledge in RAG, and push repeated reasoning patterns into the model only after production has given us enough evidence to know what it should learn.
The model will get more specialized. It will never become the whole product.
Ava is our attempt to make onchain security understandable without handing an agent control of your wallet. The Guardian lives in Telegram. Open the Guardian in Telegram
