The Summo security model.

01At a glance

Summo is non-custodial: it holds one key of three, cannot move funds on its own, and its checks on the money path fail closed. The protections that secure an account, and where each is documented in depth:

• 2-of-3 custody. The account holder controls two of three keys; Summo holds one. No single key can move funds. See the account model.
• Encrypted recovery phrase. Encrypted on the device; every release is gated and alerted. See recovery and guardians.
• Policy co-signer. Payments are decoded and checked against the account security policy before Summo co-signs. See the co-signer.
• Guardians. People the account holder chooses approve protection changes and help recover the account. See recovery and guardians.
• Sanctions and scam screening. Outbound transfers are screened against sanctions designations and known scam addresses.
• Look-alike defense. Poisoned look-alike addresses are detected, flagged, and blocked platform-wide.
• Encrypted at rest. Identity records are encrypted under a dedicated key.
• Signed releases. Code reaches production only through hardware-signed, chain-verified releases.

02Threat model

For each threat this document is built to answer: the scenario, and what happens.

• Stolen phone, locked. Keys live in the phone's hardware-backed keychain and are unreadable while the device is locked. Access is restored on a new device with the recovery phrase or through guardians.
• Stolen phone, unlocked. Every money action requires a biometric check enforced at the keychain level. A thief who passes it is still bound by any spending limit set, which caps what can be taken. The recovery phrase, and with it the backup key, is held on the phone only in encrypted form: on an account with guardians, decrypting it requires their approval, so the backup key cannot be extracted from the phone.
• Summo's co-signer key compromised. The co-signer key is one of three and cannot reach the signing threshold on its own, so a stolen co-signer key cannot move funds. Summo's servers hold no key that can read a recovery phrase on its own, so even a wider compromise of Summo could disrupt service but could not move funds or read a phrase.
• Recipient swapped server-side. Sending to a Summo contact carries the recipient's cryptographic proof of address ownership, verified independently on the sender's own device before a payment can be built. A substituted address no longer matches the stored proof, fails the check, and the send is refused. A trusted-address entry likewise exempts nothing unless its stored signature still verifies.
• Recovery phrase exposed. No defense exists. The phrase derives both keys the account holder controls: whoever holds it holds the account, and no provider control can undo that. It is shown once, stored encrypted, and every reveal is gated and alerted.
• Account sign-in takeover. Signing in on a new device never yields keys: spending requires the keys on that device, which a new device gets only from the recovery phrase or a guardian recovery.
• SIM swap. No dependency. No security control relies on SMS, so there is no phone-number path to the account or the keys.
• Address poisoning. Inbound look-alike deposits are detected and flagged in the account's activity. The decoy is blocklisted for every user, and an outbound payment to a near-twin of a previously paid address is refused before a signature exists.
• Sanctioned counterparty. Refused at the co-signing step and escalated for compliance review. The screen runs on every outbound transfer made through Summo, for every account.
• Malicious listed asset. Definitive safety failures strip the verified badge automatically, and flagged tokens are refused for purchase in the transaction path. Identity and pricing are keyed by contract address, never by name.
• Compromised swap venue. Swaps execute as one atomic batch: approve the exact amount, swap, revoke the approval to zero. No standing token approvals are left on the account, and the decoded transfers pass the same co-signing checks as sends.
• Trading venue balances. Funding a trading venue is itself a policy-checked payment. Balances held inside a venue are governed by that account's own controls, the perpetuals account is itself a 2-of-3 multisig, and withdrawals can only settle back to the account, where the spending policies apply again.
• Compromised update channel. App updates are code-signed and verified on the device against a certificate baked into the app; a tampered bundle is rejected. Publishing an update requires server-side proof of a fully signed chain of changes.
• In-app social engineering. Every payment still passes screening and any limits set, and raising those limits is itself a guardian-approved change. An attacker steering the owner's taps cannot also widen the pipe.

Out of scope. No wallet survives a phone compromised at the operating-system level, a transaction the owner intends within their own limits, or a recovery phrase read out to an attacker. Accounts without guardians keep a posture in which access to the device approximates access to the wallet; adding guardians is the recommended upgrade.

03Screening

Before Summo co-signs, every destination in the decoded transaction is checked against a single unified blocklist. A match means the payment is refused, for every account, regardless of settings.

• Sanctions designations. Government sanctions designations are mirrored into Summo's own infrastructure and refreshed several times a day, so screening never sends a transaction to a third party at payment time.
• Known scam addresses. Addresses identified in poisoning and fraud, blocked platform-wide as soon as they are listed.
• The whole transaction. Recipient and contract addresses alike are screened, and a blocked payment always gets a plain-language explanation in the app.
• Inbound transfers. Deposits cannot be refused on-chain, so an inbound transfer from a sanctioned address is flagged for compliance review instead, and Summo will not co-sign a payment back to that address.
• Accountability. Every enforcement is recorded in an append-only audit log, and sanctions events are routed into a formal compliance review process.

04Look-alike defense

Wallets truncate addresses for readability, and address poisoning exploits exactly that: an attacker plants an address that matches one in the account’s payment history at both visible ends, then waits for a mispaste. Summo’s servers always compare the complete string.

Before any payment, the destination is also compared against every address the account has transacted with. A destination that is nearly one of them, but not it, is refused, and the app shows both complete addresses side by side so the mismatch is visible. The deposit itself is never hidden: money that arrived always shows in the activity feed, flagged so the decoy cannot be unknowingly copied back out of that history.

05The freeze

If a device is in the wrong hands, the account can be frozen by replying to any security alert or by contacting support. Every money path refuses while control is regained.

• What it blocks. Sends, swaps, trading, withdrawals, and phrase release all refuse, including exits from open positions.
• Enforced twice. Once at the API boundary on every money route, and again independently inside every co-signing component, which refuses fail-closed even if an outer check were ever missed.
• Cryptographic, not cosmetic. While frozen, the account still needs two of three signatures to move anything, and the freeze withholds Summo's cooperation entirely: a thief holding only the device is left with one key and no way to reach the threshold.
• One-way from the device. A freeze assumes the phone may be hostile, so nothing reachable from the phone can lift it. Support restores access after verifying the owner.
• Ownership unaffected. A freeze suspends Summo's services, never ownership. Summo is non-custodial, and the funds remain the account holder's throughout.

Every sensitive event triggers an immediate security email: a new device sign-in, a policy change, a recovery attempt, a phrase-release request, a freeze.

06Asset safety

Every listed token is checked at listing, re-checked on a recurring schedule, and inspected again shortly before action.

• Sellability. Real sell-route probes test that a holder could exit the position, not merely that a price exists.
• Hidden transfer taxes. A token that quietly takes an excessive cut of every transfer fails its check.
• Owner powers. On Solana, mint and freeze authority are read on-chain and surfaced as cautions, and a token whose transfers execute third-party code is never verified and can never be swapped into.
• Revocation is automatic and sticky. A verified asset that definitively fails is stripped of its badge, removed from swap listings, and locked against automated re-promotion. Only a fresh human review can restore it.
• Refusal is independent of lists. The server refuses to quote a swap into any token with a failing check, badge or not, and the co-signer refuses the purchase of flagged assets for every user. Selling out of one is never blocked, so nobody is ever trapped.
• Identity is an address. Every verdict, price, and listing is keyed by blockchain and contract address, never by name or symbol. A counterfeit can copy a name; it cannot inherit a price, a badge, or search placement.

07Data protection

How stored data and account actions are protected.

• Personal data. Identity records are encrypted at rest with AES-256-GCM under a key dedicated to identity data, separate from the application's other keys. Identity documents are never stored by Summo.
• Signed actions. Sensitive account actions carry a signature from the device key of the person performing them, in the EIP-712 typed-data standard, and Summo verifies that signature before the action takes effect. Guardian invitations, guardian votes, and trusted-address additions all work this way, so none of them can be performed from a sign-in session alone.

08Release integrity

Every change passes the same checks before it reaches production or a phone.

1. Gated. Before a release can be signed, tooling runs static security guards and the full automated test suite.
2. Signed. Releases are signed with a key resident in a hardware secure element, gated by biometric approval, and every change since the previous release must carry a valid signature from a trusted key.
3. Verified independently. The production server re-checks everything itself: the release signature against a pinned allow-list, then every commit in the chain.
4. Delivered signed. App updates are signed with a dedicated key, and the phone verifies every update against a certificate baked into the app binary. A tampered bundle is rejected on the device. Store builds are additionally covered by the platforms’ own signing and review.

09Scope and contact

This document describes security controls at the architecture level. The document is checked against the shipped system and updated as the model evolves, and withholds operational specifics such as exact thresholds, detection heuristics, rate limits, and internal topology.

Security researchers who believe they have found a vulnerability can write to [email protected]. Reports go straight to the engineering team.