ZeFi Intelligence
The intelligence
layer
ZeFi Intelligence is the conversational surface and the intent-processing engine behind it. It answers questions about crypto, reads a connected wallet, and turns a sentence into a structured, validated transaction plan.
Try asking
- “Explain what is in my wallet.”
- “How much stablecoin exposure do I have?”
- “Create a plan to move 500 USDC from Ethereum to Base.”
- “What approvals would this transaction require?”
ZeFi Intelligence
The assistant that
knows what it cannot see
Most crypto assistants are a chat box in front of a search index. ZeFi Intelligence is wired into a chain registry, a wallet reader, and a deterministic planner — and it is explicit about the boundary between them.
How much stablecoin exposure do I have?
Across the three networks ZeFi read at 09:41 UTC, 24,660.55 USDC is about 51% of the 48,213.55 total — all of it USDC, none in USDT or DAI.
That concentration is a single-issuer position as much as a currency one: every one of those units depends on the same redemption process. Splitting across issuers changes the failure mode, though it does not reduce it.
This covers the assets in ZeFi’s verified registry. Tokens outside it are not included in the total.
Example exchange. In the product these figures come from a live read of your connected wallet, and the reply is generated by the configured model.
Explains, without hedging
Protocol mechanics, contract behaviour, and the trade-offs a decision actually turns on — answered at the depth the question deserves.
Reads your wallet, and cites the time
Balances come from your connected wallet over configured RPC endpoints. Every figure carries the moment it was read.
Turns intent into a typed plan
A sentence becomes an action, networks, an asset, an amount and a recipient — validated against the registry before anything is built.
Says when it does not know
No live price, no balance read, no route quote — ZeFi reports the gap. It will not fill a missing number with a plausible one.
The pipeline
Eight stages, two of which touch a model
Everything that could reach a transaction sits between stage two and stage seven — and none of it originates in a language model.
- 01
Classify the request
A deterministic classifier runs first and gives the model a prior. It is also the complete classifier when no AI provider is configured.
- 02
Extract structured intent
A forced tool call produces a typed object — the same contract on either provider. It is parsed with Zod; a schema mismatch gets one repair attempt, then becomes an error.
- 03
Determine missing information
Chains and assets are resolved against the registry, addresses are checksummed, amounts are range-checked against real decimals.
- 04
Retrieve permitted context
Only the wallet reads this intent actually needs, on the server, over configured RPC endpoints — each stamped with its read time.
- 05
Construct a plan or an answer
Transactional intents go to the deterministic planner. Everything else is answered directly, with the wallet context attached.
- 06
Deterministic validation
Local simulation checks chain, wallet, recipient, asset, amount, balance, approval scope and encodability.
- 07
Generate the explanation
The model is given the finished plan and asked to explain it. It cannot change a value; it can only describe one.
- 08
Present for review
The plan, its risks, its provenance and its confirm label are returned together. Nothing proceeds without a human.
Guarantees
What holds regardless of what the model says
Numbers never originate in the model
Addresses, decimals, chain ids and contract references come from the registry. Amounts come from the user, validated as decimal strings and converted with BigInt — never through a float.
Untrusted text is framed as untrusted
User messages are sanitised of control characters and bidi overrides, then wrapped in delimiters the system prompt identifies as data. The real defence, though, is structural: model output has no path into transaction data.
Failure is reported, not papered over
A configured provider that fails produces an error. It never silently becomes a fixture, and demo mode never activates as a fallback.
Timeouts and retries are bounded
Requests carry an explicit timeout and at most two provider retries. Structured generation gets exactly one repair attempt before giving up honestly.
Model configuration
ZeFi does not hardcode a model identifier anywhere in its source, and it does not hardcode a vendor either. The provider sits behind an interface with two shipped implementations — OpenAI by default, Anthropic via AI_PROVIDER=anthropic — and the model comes from OPENAI_MODEL or ANTHROPIC_MODEL. An operator picks what their key is entitled to use, and the deployment does not break when a model name is retired. If neither is configured, the AI layer reports itself unavailable rather than guessing.