Trust assumptions

Non-custodial does not mean trustless. An honest map of what HEVN relies on, what a failure of each dependency would mean, and how each one is bounded.

Every real system relies on something. Rather than claim HEVN is “trustless”, this page lists exactly what the architecture depends on, what happens if each dependency fails, and how each dependency is deliberately kept narrow.

The map

Dependency	Relied on for	If it fails	How it’s bounded
Coinbase Smart Wallet contracts	Wallet logic: ownership, spend permissions, nonces	A contract bug would affect every Base Account user, not just HEVN	Open-source, audited, canonical deployments — addresses are verifiable on Basescan
Base network	Settlement of every transaction	Outage delays transactions; funds and state remain onchain	Public L2 with public explorers; nothing HEVN-specific
Privy	Key management; email → key mapping	Outage delays signing; permanent failure → key export escape hatch	Shamir + TEE model, attestation; key export as the exit hatch
Licensed banking partners	Fiat legs: deposits and payouts	A payout in progress depends on the partner completing the fiat leg	One-time addresses per payout; HEVN never holds the money; no pooled balances
NEAR Intents / 1Click	Cross-chain swaps; in-flight settlement	Failed or expired intents follow the refund flow — for withdrawals, back to your HEVN wallet	One-time quote-bound addresses; trust scoped to one swap at a time
CDP Paymaster	Gas sponsorship for gasless USDC	Unavailability delays operations; it can never initiate or alter them	A paymaster only pays fees under ERC-4337
HEVN platform	Metadata (contacts, invoices, bank details) and the UI you see	Metadata tampering; display is protected by signed provider responses	No keys, no owner role, no custody — cannot sign a wallet operation

What HEVN deliberately does NOT rely on

Just as important is what is absent from the trust map:

• No HEVN key can move funds. Money authorization terminates in a signature from the user’s key or an owner-granted, contract-capped spend permission — never in a backend decision.
• No omnibus accounts. There is no pooled HEVN balance whose solvency you would have to trust; every balance is an individual onchain wallet.
• No proprietary contracts. HEVN deploys Coinbase’s audited standard as-is instead of writing its own wallet logic.
• No lock-in. The exported key controls the wallet with standard Ethereum tooling, independent of HEVN and Privy.

Shrinking the map over time

The roadmap reduces the remaining assumptions rather than adding new ones: independent audits of the provider microservices and moving them into TEEs with attested builds, so their guarantees are verifiable rather than taken on trust.