01
AI proposes
The language model creates a bounded candidate interpretation and helps manage a multi-step conversation. Model output is a proposal, never evidence of an onchain fact or signing authority.
Human-authorized AI app layer
AI proposes.
Evidence constrains.
Your wallet authorizes.
DeSpell is the application layer between a person’s intent and a wallet request. AI produces a bounded candidate; verified registries, deterministic reconciliation, provider adapters, role-aware checks and point-in-time simulation must agree before the person is asked to authorize.
Jump to protocol onboarding01
Human first, AI native
The interface is AI. The authority is human.
Most agent narratives begin by asking how much control can be delegated to AI. DeSpell starts from the opposite direction: give AI enough context to plan the whole job, but keep ownership, inspection and approval with the person.
02
Systems verify
Original user spans, verified registries, provider evidence, server-authenticated artifacts and simulation establish the material facts independently of the model.
03
Humans authorize
Review surfaces show the chain, token, amount, recipient, target, spender and approval scope. The user’s wallet remains the only signing authority.
02
Execution architecture
Language is flexible. The execution boundary is rigid.
The LLM is deliberately outside the signing and security boundary. DeSpell’s normal proposal path requires the original request, verified material facts, a selected provider path, a server-prepared transaction, the active signer and the wallet review to remain consistent.
01
Raw intent evidence
The original message, exact spans, corrections, negations and cancellations are preserved. A model guess does not silently replace what the user said.
02
Bounded model candidate
The model may propose fields, but model-supplied addresses, contracts and amounts cannot become executable facts without independent provenance and verified resolution.
03
Deterministic reconciliation
Rules reconcile the candidate with the user’s evidence and server-authenticated plan context. Conflicts, unsupported facts and material ambiguity become a question, not a transaction.
04
Verified resolution
Chain IDs, token contracts, decimals, integer base-unit amounts and recipient roles resolve through registries and RPC evidence before execution preparation.
05
Provider-neutral routing
LI.FI, deBridge, Across and GIWA stay behind adapters that pair quote normalization with transaction-preparation semantics. The client receives a bounded common contract.
06
Identity-bound artifact chain
A 90-second AES-256-GCM encrypted route ticket binds the user, session, signer, query, recipient and selected provider response without exposing the raw provider payload to the client. Separate HMAC commitments bind the final transaction fields. Neither artifact is a user signature or provider attestation.
07
Transaction inspection + simulation
The prepared target, calldata, value, chain and signer must exact-match an expiring commitment. Address roles and approvals are inspected before a point-in-time source-chain simulation.
08
Wallet authorization + observed state
The user reviews and signs. DeSpell separates authorization, hash submission, source-chain confirmation, revert and unknown status; an unknown result is not silently retried or reported as success.
03
Route intelligence
Optimization is a normalization problem before it is a ranking problem.
DeSpell queries registered adapters concurrently under provider-specific timeouts and converts every executable response into one bounded common contract. It then selects up to three representatives from the live candidates returned: highest net after costs, shortest estimated duration and smallest expected-to-minimum output gap. One adapter failure or oversized response does not discard another adapter’s valid candidates.
toAmount / toAmountUsd
Provider-quoted destination output. Swap and bridge comparisons re-price it at an independent market price instead of the provider's own USD, and drop a route that returns more than 15% less than the market; raw output ranks only when the destination has no market price.
toAmountMin
Provider-supplied output floor or quote constraint. Its exact semantics can differ by adapter; it is not a liquidity guarantee.
durationSec
Provider or adapter estimate for the route, not a settlement SLA.
feeTotalUsd / gasCostUsd / separateFeeUsd
Shown separately when supplied. Source gas and provider fees paid outside the quoted output are deducted from the ranking; fees already inside the output are not deducted twice. Missing data is unknown, not zero.
NET AFTER COSTS
Compare destination value minus source gas and provider fees the wallet pays outside the quote. A route with a cost that cannot be priced does not beat a route whose costs are known; when no candidate has USD, exact raw output is compared for the same destination token. This is not an all-in net-cost guarantee.
ESTIMATED TIME
Compare normalized provider or adapter duration estimates and expose the live path. The estimate is not a settlement SLA.
QUOTE FLOOR GAP
Compare the gap between expected output and the provider-supplied floor. This is neither a liquidity rating nor a protocol-safety score.
FRESHNESS
After ERC-20 approval, DeSpell fetches a fresh quote. An unchanged reviewed structure, warning fingerprint and non-decreasing minimum can resume automatically. If the same route family remains but price, structure, protocols or warnings changed, DeSpell keeps the closest route selected and requires one fresh human review; only a missing family reopens route choice. No automatic match authorizes a changed transaction.
04
Defense in depth
No single model, provider or score can declare a transaction safe.
Security comes from independent boundaries that must agree. Hard integrity, contract-existence and simulation failures block execution. Inconclusive recipient reputation or history is never shown as safe; it becomes a review state requiring explicit confirmation.
01 / authority
Signer and session binding
SIWE proves control of an address, not a person’s identity. Every execution is authorized by the active signer in its own interface, and the execution gate re-checks that the wallet-session address is the address that will sign.
02 / integrity
Server-authenticated, expiring artifacts
The route ticket is an authenticated AES-256-GCM ciphertext; plan context and transaction commitments use server-secret HMACs. They check integrity, scope and expiry, but are not user signatures or proof that provider data is correct. In production and preview, route nonce, API rate limits and SIWE challenges use atomic TTL operations in shared Redis across instances. Development and tests use memory; non-local deployment fails closed with 503 if the shared store is absent or unavailable.
03 / transaction
Approval and recipient inspection
ERC-20 approvals are decoded and scoped to the route input amount. Token contracts, spenders, recipients and execution targets are checked by role instead of being collapsed into one address score.
04 / outcome
Simulation and observed transaction state
Every supported proposal requires a successful point-in-time source-chain simulation; direct transfers and multisends also reconcile recipient effects. For an ordinary external EOA, DeSpell has no server-side broadcast gate after simulation: the wallet is the final execution boundary, and its signature is not cryptographically bound to the simulated request. A source-chain receipt does not by itself prove destination settlement.
Trust assumptions
Every dependency has a bounded job, and a failure mode.
DeSpell reduces the authority of any one component, but it does not remove trust. The boundaries below state what each dependency can influence and what its compromise could mean.
DeSpell application and server
The application presents facts and the server resolves intent, issues expiring artifacts and prepares transactions. A compromised application or server could misrepresent a request or produce a harmful candidate. It still cannot create an external-wallet signature, but a person can be deceived into signing; wallet review and application integrity therefore remain material.
Passkey account and connected wallets
The passkey private key is created and held by the device authenticator and never leaves it. ZeroDev’s passkey server holds only the WebAuthn public key and credential ID, so its outage blocks sign-in but cannot produce a signature or move funds. The bundler can delay or drop a UserOperation but cannot alter one that is already signed. A separately connected wallet keeps signing and recovery inside its own provider. DeSpell does not request a seed phrase or hold a private key on either path, but availability and wallet presentation remain dependencies of those providers.
Language model and data processors
The model can misunderstand, omit or invent fields, and prompt content is processed by the configured model provider. Model output cannot authorize a transaction; material values must survive evidence extraction, deterministic reconciliation and verified resolution. Provider confidentiality and availability still remain operational trust assumptions.
RPC, routing, reputation and simulation services
Third parties supply chain state, quotes, calldata, risk signals and point-in-time simulation. Their data can be stale, incomplete, unavailable or wrong. DeSpell cross-checks roles and exact transaction fields and fails closed on hard integrity or simulation errors, but these checks are not independent proof that a protocol or destination settlement is safe.
Key management
DeSpell coordinates authorization; it does not receive a seed phrase.
There are two signer paths, a passkey smart account and an external wallet. Their custody, recovery and failure assumptions are different and should not be described by one unqualified “non-custodial” label.
Passkey smart account
A DeSpell account is one passkey signing for an ERC-4337 Kernel smart account. The passkey is created and held by the device authenticator, so there is no seed phrase, no DeSpell-held key and no email execution code. DeSpell’s application code does not receive or persist a private key, and the server cannot sign a UserOperation on the account’s behalf.
External wallet
A browser or mobile wallet remains a separate connector session and signs directly in its own interface. SIWE proves current control of the address for the session; it does not identify the person, recover the wallet or protect a compromised extension, device or wallet interface.
Recovery and operator access
DeSpell cannot recover an external-wallet seed phrase, and it cannot recover a passkey either. Access to a passkey account depends on the device, or on the platform passkey sync you configured, such as iCloud Keychain or a password manager. DeSpell server secrets authenticate short-lived application artifacts; they are not user keys and cannot by themselves produce a wallet signature.
05
Defensibility
The technical edge is verified intent-to-transaction correspondence.
The correspondence layer checks whether user evidence, verified chain facts, live route candidates, exact transaction fields, signer scope and observed source-chain state remain consistent. Browser integrity, wallet presentation and destination settlement remain separate trust boundaries.
DeSpell has technical differentiation, not yet a proven business moat. Defensibility must still be earned through repeated operator use, proprietary outcome data, reusable policy and independent assurance.
On the frozen internal 1,000-case intent corpus, the raw model reached action macro-F1 0.919 and 618/629 required-slot exact matches (98.25%). Evidence reconciliation and verified resolution passed 1,000/1,000 overall and 990/990 reconciliation cases, with five predefined unsafe metrics at zero. This is reproducible internal regression evidence, not independent certification or a claim of universal language accuracy.
Technical differentiation shipped today
Provenance-aware reconciliation
Original spans, corrections, negations, cancellations, aliases and revisions remain attached to the decision instead of being overwritten by a model guess.
Provider-neutral route semantics
Each adapter owns both quote normalization and transaction preparation behind one display and security contract, so provider payloads do not define client policy.
Server-authenticated evidence chain
An expiring authenticated-encryption route ticket and separate HMAC commitments bind plan context, signer scope, route facts and the server-prepared transaction across approval and re-quote boundaries.
Ambiguity-safe state machine
Submitted, source-confirmed, reverted and unknown states remain distinct. Uncertain results are not silently retried, and fresh quotes cannot silently change route identity.
Failure-derived regression system
Every release has to pass the full automated product and security regression suite. A fixed 1,000-case intent corpus and a repeated three-persona conversation QA cycle turn real language failures into reproducible engineering constraints instead of one-off patches.
Planned compounding layers - not yet deployed
Workflow graph
Safely resumable, multi-wallet and multi-chain jobs that preserve dependencies and approval boundaries.
Outcome data
Quoted versus received amount, duration, failure reason and signer/provider compatibility, measured without storing private conversation content.
Operator policy
Reusable address allowlists, amount limits, protocol rules and team approvals tied to execution evidence.
Verified playbooks
Human-approved workflows whose intent, transaction and outcome history improve future recommendations and switching cost.
06
Protocol onboarding
Contract Intelligence Registry
The Registry turns chain-bound contract addresses into a read-only Protocol Passport before DeSpell asks a project for more information. Contract addresses are evidence to analyze, not permission to execute.
Analysis and execution eligibility are separate states. A submitted or verified contract is not automatically safe, integrated or executable, and the LLM never creates a contract address, spender, calldata or enablement decision.
01
Submit network + deployments
A project submits one Chain ID and up to five public contract addresses as one deployment slice. User-supplied RPC, explorer, source, private keys and API secrets are outside the schema.
02
Analyze onchain evidence
DeSpell pins addressable reads to one observed block, reads runtime bytecode and codehash, resolves common EIP-1967, Beacon and EIP-1167 proxy evidence, compares source and ABI evidence, and identifies a bounded set of standard and protocol-role candidates.
03
Create a Protocol Passport
The snapshot separates Verified, Partial, Inferred, Unknown and Mismatch evidence, preserves the proxy interaction address separately from implementation code, and produces an evidence fingerprint that is an identifier, not a certificate.
04
Request only missing facts
The follow-up Form asks for official roles, intended actions, successful transactions, upgrade and incident policy, eligibility rules, and API, solver, relayer or signed-quote dependencies the chain cannot prove.
05
Verify before enabling
Candidates progress through Preview-only → Testnet → Controlled mainnet only after an explicit adapter, reproducible quote semantics, exact approval targets, simulation, settlement evidence and human review.
06
Re-analyze changes
A changed proxy implementation, codehash, admin or material dependency requires a new snapshot and review. Form answers never bypass re-analysis.
Where this shortens integration
Public EVM deployments that resemble the currently supported token, AMM, router, factory, quoter, pool, ERC-4626 and bridge-component interfaces can enter evidence review faster because the first static checks and missing-fact questions are prepared automatically.
Where CA analysis is not enough
The MVP is not a general staking, lending, farm, gauge, Curve/Balancer, call-graph, source-AST or trace analyzer. RFQ or solver swaps, relayer-funded bridges, offchain signed quotes, private liquidity, custom execute(bytes) semantics, destination settlement and refund policy still require official evidence and may require an API, SDK or hand-built adapter.
Roles and risk
Controls reduce risk. They do not eliminate it.
DeSpell
DeSpell operates the controls described here: it reconciles the request, presents available provider evidence, checks the prepared transaction and reports the transaction states it can observe. These controls may be incomplete or fail.
The user
The user decides whether to proceed and authorizes each wallet request. Before authorizing, review the chain, token, amount, recipient, execution target or spender, fees and approval scope.
Wallets, providers, networks and protocols
Third parties supply data or execute transactions under changing conditions outside DeSpell’s control. Quotes and status data can be delayed, incomplete or change before settlement.
Onchain actions may be irreversible. Information shown by DeSpell supports product operation and is not intended as personalized investment, legal or tax advice. DeSpell does not guarantee safety, execution, destination settlement, returns or principal. These roles do not assign all losses to the user or exclude rights or responsibilities that cannot lawfully be excluded.
07
Supported scope
Execution runs on a named list, not on every chain.
Execution coverage and portfolio reading are two different scopes, so DeSpell states both instead of implying universal support. A chain that DeSpell can read is not automatically a chain DeSpell can execute on.
DeSpell does not claim support for every chain and every token. Anything outside the execution list below is read-only or unsupported, and the interface is expected to say so rather than improvise a route.
Execution mainnets
Twelve networks carry the execution path today: Ethereum, OP Mainnet, BNB Chain, Unichain, Polygon, Soneium, Robinhood Chain, Base, Arbitrum, Avalanche, Linea and Scroll.
Execution test networks
The Sepolia family used for rehearsal, covering the Ethereum, OP, Base and Arbitrum Sepolia networks plus BSC Testnet, together with GIWA Sepolia.
What a new chain has to clear
A network joins the execution list only after RPC identity, simulation, token and route discovery, wallet chain switching and measured routing all work against it. Provider coverage on paper is not sufficient on its own.
Portfolio reading is wider than execution
Balance reading spans more networks than execution does. Custom chains and manually added token contract addresses are display-only: they carry no USD valuation, and their presence in the portfolio is never evidence that an execution path exists for them.
GUIDED SOURCE SELECTION
When a request does not name the source asset, DeSpell opens a portfolio picker instead of guessing, and destination, amount and confirmation stay on one card with a single submit. That convenience does not move the execution boundary: the amount is recomputed in integer base units from RPC balance evidence, the transaction commitment still has to match exactly, point-in-time simulation still runs, and the wallet still performs the final signature.
Current stage / August 2026
Open free beta on mainnet. Every execution is still human-authorized.
Mainnet execution is open to any authenticated wallet that passes signer-ownership verification; there is no execution allowlist. Opening the scope did not remove the controls: the original request is still reconciled against the user’s own spans, routes are still reviewed before preparation, a single-use encrypted route ticket and separate transaction commitments still bind the prepared call, recipient and approval-scope checks and point-in-time simulation still run, and the user’s wallet remains the only signing authority. Release policy can narrow the scope again. Automated tests and internal review are engineering evidence, not independent assurance; an independent security audit is not yet complete. Production uses shared atomic security state and fails closed when it is unavailable. Stricter script/connect CSP restrictions and broader mobile-wallet end-to-end tests remain pending. For bridges, source-chain confirmation does not by itself prove destination settlement, and automatic bridge-to-multisend continuation is disabled in production and preview. The beta is free to use; execute only amounts you can afford to lose.