Security model
How custody, authentication, and card data flow through OmniHood — and where the trust boundaries are.
Security in OmniHood is designed so the app never holds funds you didn't just send it for a specific transaction. Everything else lives in your wallet, at your issuer, or on-chain.
Non-custodial trading
- Your wallet holds your tokens. Swap, bridge, and LP flows are transactions you sign — OmniHood never has a private key that can move your funds.
- Session cookies do not equal fund access. The
kripi_sessioncookie proves you signed the auth message. It scopes what data you can read (your own cards, your own LP position), but every token movement still needs your signature.
Wallet authentication
The verified wallet identity comes from a signed EIP-4361 (Sign-in-With-Ethereum) or Solana message stored in your session cookie. Every route that:
- reads your data (cards, ledger, LP position),
- executes a server-signed transaction on your behalf (fee flows, launcher deploys),
- or writes to a per-wallet store (payout wallets, card fee claims)
opens with getVerifiedOwner(req) and rejects if the cookie is missing or forged. There is no path in the codebase that trusts a wallet address supplied in a request body or query string.
Card data
- PAN and CVV never touch OmniHood servers. They live at the card issuer (KripiCard). When you tap Reveal, your browser fetches them directly from the issuer's API using a short-lived token.
- The app stores only the card_id ↔ wallet mapping in its own database — a lookup index, no card details.
- The card issuer holds a pooled USD balance across all users' cards; per-wallet ownership of that balance is enforced by OmniHood's ledger, which routes every reserve/debit/credit and prevents one wallet from spending another's funds.
Card fees & burns
- Card creation is verified against Relay's
/requests/v2API before granting a credit. The check confirms:- the payment settled,
- it delivered OMHD on Robinhood Chain,
- to the burn address (not somewhere else),
- paid by this wallet's EVM address,
- and worth ≥ the card fee.
- Every OMHD burn has a real Robinhood Chain tx hash — verifiable by anyone. Only confirmed burns count in the "OMHD burned" homepage stat.
Omnichain — the LayerZero mesh
- 3-DVN stack by default: LayerZero Labs + Nethermind + Horizen. Every cross-chain message must be attested by all three before delivery.
- No single DVN can move funds. A compromise of any one verifier is contained.
- Enforced options set an explicit gas budget for the destination-side
lzReceive, so a malformed message can't leave a delivery stuck.
Staking
- The OMHD staking vault is a non-custodial contract on Robinhood Chain. Only you can withdraw your stake.
- The server only reads
stakedOf(address)— it can never move or slash your stake. - No hidden penalty; no timelock by default.
Managed keys (for automated flows)
Some flows use server-held keys (the price signer for RFQ trades, the sponsored-Solana executor for card top-ups). These keys are:
- Isolated per role — the swap signer can't move card funds and vice versa. A single leak can't reconstruct the others.
- Rotatable — every gate the signer authenticates against has a
setSigner(address)function callable only by the deployer. Rotating a key doesn't require redeploying contracts. - Stored as ciphertext in the wallet vault; a
LocalKekabstracts key encryption for a straight port to a KMS (AWS KMS, GCP KMS) in production hardening.
What OmniHood does NOT do
- Does not hold seed phrases — Privy embedded wallets use MPC.
- Does not have a "recover funds" admin function on any contract we control.
- Does not read your other cards / other on-chain activity. The app only queries balances and history for tokens/chains you're actively using in the UI.
Where to review the code
Every contract is source-open in the OmniHood repos:
- OmniHoodStakingVault — non-custodial OMHD staking
- OrderGate — RFQ / cross-chain fill (in
omhd-liquidity) - ANSEM OFT / OMHD OFT — LayerZero deployments (in
omhd-oft) - Card fee, cashback, and ledger modules — in
lib/of the main app
Formal audit is planned before hard gates (staking-required card issuance, etc.) are enabled by default.
