> ## Documentation Index > Fetch the complete documentation index at: https://hevninc.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Security model > A summary of HEVN's trust boundaries: what each party can do, what happens in failure scenarios, and how to protect your account. HEVN's security posture follows from one design decision: **the platform never holds keys or funds**. What the system does rely on is mapped honestly in [Trust assumptions](/general/trust-assumptions). Everything else — the [Privy key layer](/general/privy-wallets), the [Base smart wallet](/general/smart-wallets), [one-time payout addresses](/general/deposits-and-payouts), [1Click passive deposits](/general/cross-chain) — exists to keep that invariant true on every flow. ## Custody matrix | Asset | Where it lives | Who controls it | | -------------------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | Private key | Sharded (Shamir) across the user's session and Privy's TEE infrastructure; never assembled outside a TEE | User only | | USDC balance | The user's smart wallet contract on Base | Onchain owners only (the user, plus anyone they [explicitly added](/general/shared-access)) | | Bank details, invoices, contacts | HEVN backend | HEVN, scoped by the user's JWT / API keys | | Funds in a fiat payout | Banking partner's one-time address, then bank rails | Banking partner, for that payout only | | Funds in a cross-chain swap | 1Click settlement layer, per one-time quote | NEAR Intents protocol, for that swap only | ## Failure scenarios Funds at rest are unaffected. No HEVN system holds a wallet key or an owner role: an attacker with full control of HEVN's backend could read and tamper with metadata (invoices, contacts, bank detail records) but could not sign a single wallet operation. The wallet itself remains accessible through Privy — or via [key export](/general/privy-wallets#exit-hatch-key-export) — and standard Base tooling; it is an ordinary onchain smart wallet. The honest residual risk is **display integrity**: a compromised platform could try to show a false destination address (a fake payout or deposit address) and let the user sign a transfer to the attacker. HEVN's primary defense is [provider isolation with signed responses](/general/architecture#provider-isolation-signed-responses): payout details and one-time deposit addresses are fetched and signed by dedicated per-provider microservices, and the client verifies the signature before displaying anything — a forged address from the main backend fails verification. The last line of defense is still the signer: for large transfers, verify the destination through an independent channel before signing. A leaked JWT exposes the platform surface only: reading data and editing metadata — no spending. A leaked API key adds, at worst, spending **within the onchain allowance the owner granted it** for the current period — the [`SpendPermissionManager`](/general/shared-access#limited-access-spend-permissions) contract rejects anything beyond that. Revoke the spend permission onchain and the key in the app; the wallet owner key itself is never exposed. See [Authentication](/general/authentication#api-keys-cli-rest-api-agents). An outage delays signing (you temporarily can't authorize new operations), and no one else gains any capability during it. For the extreme case, the escape hatch is [key export](/general/privy-wallets#exit-hatch-key-export): the exported owner key controls the smart wallet with standard Ethereum tooling, independent of both Privy and HEVN. Privy is a deliberate trust assumption of the current architecture — see [Trust assumptions](/general/trust-assumptions). This is the critical scenario. Without wallet MFA, whoever controls your email can complete Privy authentication and unlock the wallet. With [wallet MFA](/general/privy-wallets#wallet-mfa-passkeys-and-otp) enrolled, email access alone is not enough — every key operation also requires your passkey or OTP code. Enable MFA and protect the email account itself — see below. This is the one scenario with no backdoor — by design. Privy [cannot recover an account or change its login methods](https://www.privy.io/user-help-center): no party, including HEVN, can reassign your identity to a new email. That is the same property that protects you from account takeover. Prepare in advance: * **Link a second login method** (e.g. Google alongside email) — losing one still leaves the other. * **Add a trusted full-access co-owner** ([Shared account access](/general/shared-access)) — their wallet access is independent of your login, so the funds stay reachable even if your identity is lost entirely. Removing or replacing an MFA method [requires completing MFA first](https://docs.privy.io/authentication/user-authentication/mfa/advanced) — there is no administrative reset, by HEVN or by Privy. That is deliberate: a support-desk override would be a backdoor into everyone's wallet. Losing your **only** factor therefore locks wallet operations, so treat MFA factors like keys: * Enroll **at least two factors** (e.g. a passkey **and** a TOTP app) — losing one still leaves the other. * If there is someone you trust with the account, **add them as a full-access co-owner** ([Shared account access](/general/shared-access)) — their access does not depend on your factors. Nothing is lost. The account is fully re-derivable from your email identity: sign in on any device, complete Privy auth, and your wallet is available. There is no device-only secret and no seed phrase. The blast radius depends on the access mode ([Shared account access](/general/shared-access)). A **full owner** controls not just the money but access itself — they can spend the entire balance and add or remove other owners, including you. Grant that only to people you trust with the whole account. A **limited spender** is capped by the onchain spend permission: worst case, they drain the remaining allowance for the current period, nothing more. Either way, remove the owner or revoke the permission onchain; once confirmed, their key is cryptographically inert for this wallet. 1Click's intent lifecycle includes automatic settlement tracking and refunds; failed or expired intents return funds to the sender. See [Cross-chain deposits & withdrawals](/general/cross-chain). ## Protect your email Your email (or Google account) is the root of your HEVN identity. Recommended baseline: * Enable **[wallet MFA](/general/privy-wallets#wallet-mfa-passkeys-and-otp)** — a passkey or authenticator-app OTP required for every wallet operation, so a compromised mailbox alone cannot move funds. * Enable **2FA** on the mailbox — preferably hardware security keys or passkeys, not SMS. * Use a mailbox provider with strong account-recovery hygiene; lock down recovery phone numbers and backup addresses. * For business accounts, use a dedicated, access-controlled mailbox rather than a personal one. ## Contract and infrastructure assurances * The smart wallet contracts are Coinbase's open-source [Smart Wallet](https://github.com/coinbase/smart-wallet) (audit reports in the repository), running unmodified on Base under the canonical [ERC-4337 EntryPoint](https://eips.ethereum.org/EIPS/eip-4337). * Key management inherits Privy's security model: Shamir's Secret Sharing plus TEEs with attestation. See [Privy security](https://www.privy.io/security). * Every money movement is a public Base transaction, independently verifiable on [Basescan](https://basescan.org) — statements in HEVN are projections of onchain truth, not the source of it. ## Responsible disclosure Found a vulnerability? Report it privately to **[p@gethevn.com](mailto:p@gethevn.com)** — include reproduction steps and impact. We triage every report and keep you updated through the fix. Good-faith research conducted this way will never result in legal action from HEVN.