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. Everything else — the Privy key layer, the Base smart wallet, one-time payout addresses, 1Click passive deposits — 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)
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

HEVN is fully compromised or disappears

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 — 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: 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 HEVN JWT or API key leaks

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 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.

Privy has an outage — or disappears entirely

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: 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.

Your email account is compromised

This is the critical scenario. Without wallet MFA, whoever controls your email can complete Privy authentication and unlock the wallet. With wallet MFA 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.

You lose access to your email account entirely

This is the one scenario with no backdoor — by design. Privy cannot recover an account or change its login methods: 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) — their wallet access is independent of your login, so the funds stay reachable even if your identity is lost entirely.

You lose your MFA factor (passkey or authenticator)

Removing or replacing an MFA method requires completing MFA first — 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) — their access does not depend on your factors.

You lose your device

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.

A teammate with shared access goes rogue

The blast radius depends on the access mode (Shared account 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.

A cross-chain swap fails mid-flight

1Click’s intent lifecycle includes automatic settlement tracking and refunds; failed or expired intents return funds to the sender. See Cross-chain deposits & withdrawals.

Protect your email

Your email (or Google account) is the root of your HEVN identity. Recommended baseline:

• Enable wallet MFA — 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 (audit reports in the repository), running unmodified on Base under the canonical ERC-4337 EntryPoint.
• Key management inherits Privy’s security model: Shamir’s Secret Sharing plus TEEs with attestation. See Privy security.
• Every money movement is a public Base transaction, independently verifiable on Basescan — statements in HEVN are projections of onchain truth, not the source of it.

Responsible disclosure

Found a vulnerability? Report it privately to [e-mail] — 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.