Your keys, your coins, your consent.
Hardware wallets proved who holds the keys. SoM Sig proves the key-holder is acting freely — on-device, hardware-rooted, self-custodial, and bound to every signature your wallet produces. The consent-provenance layer the crypto stack has been missing. Coercion-resistant. Privacy-preserving. No third-party trust required.
Crypto's risk surface moved from online to physical.
A decade ago, crypto threats lived in your software stack — phishing, malware, key compromise. In 2024–2026 they live in your front door, your dating app, and your DM screen. The signature primitive is the same; the attacker is closer.
Wrench attacks & flash kidnapping.
Crypto's irreversibility makes physical coercion uniquely effective. From the Ledger CEO kidnapping in early 2025 to a documented surge of home invasions targeting known holders, the "$5 wrench" is no longer a meme. Identity-proven, in-pocket hardware-signed transactions are exactly what an attacker wants: irreversible, untraceable to recovery, instant.
Pig butchering & long-running scams.
Months of grooming, a fake investment platform, a friendly "guide." The victim signs freely — but not with intact understanding. By the time they realize, the funds are gone on a chain that does not forgive. FBI IC3 reported pig-butchering and crypto-investment scams as the single largest category of consumer financial loss in the United States in recent reporting.
Signed approvals you didn't really agree to.
Drainer kits trick users into signing token approvals or transaction hashes whose semantics they don't grasp. The signature is cryptographically valid; the consent is not informed. Address-poisoning, malicious permit2 approvals, and lookalike-domain phishing have industrialized this. Hardware wallets prove the key; nothing in the stack proves the understanding.
Your wallet signs whatever you tell it to.
There is no record of state of mind. No defense against a wrench at your kitchen table. No friction on the malicious approval you skim-read. Once broadcast, the transaction is final. There is no fraud team to call. The user is the last line of defense, and the user just signed.
Every signature carries provenance of clear consent.
Wallet policy can hold transactions where indicators show distress, confusion, or coercion. Disputes have evidence. Insurance has a basis. Recovery flows have a starting point. The wallet still does what you tell it — once it's verified that the "you" is freely you.
A home invasion. The same wallet, with one policy enabled.
Marcus is a known builder in the crypto space. Public profile, on-chain footprint, visible holdings — the kind of person Lopp's tracker is full of. One evening, two attackers force entry. Here is how the next two minutes unfold with SoM Sig in his wallet's signing flow.
12.4 BTC.
Sign & broadcast.
The wallet still did what its owner instructed — it sealed the signature, exactly as Marcus pressed sign. What it refused to do was broadcast a transaction whose signing was accompanied by high-confidence coercion indicators, against Marcus's own pre-set policy. The cryptographic primitive grew a consent-provenance layer. That layer is what made the funds recoverable, the encounter survivable, and the policy itself something an attacker cannot defeat.
Self-custody is the point. We don't break it.
The crypto community has spent a decade building hardware-rooted trust for keys. We're extending that to consent — not replacing it with a new trust party. These are guarantees we commit to in our developer agreements.
If any of these guarantees are broken, the integration is broken. We treat them as load-bearing. Independent audit of the verification stack is a precondition for our v1.0 launch into the wallet ecosystem.
More detail in the protocol specification → /spec/som-wallet-protocol-v1
- On-device only. Raw biometric data — frames, audio — never leaves the user's hardware. Capture, scoring, and signing happen inside
Secure Enclave/StrongBox/TPM 2.0. We do not have an API to retrieve it. No exception. - No server required. For self-custody wallet flows, RTScale runs entirely standalone. No connection to our cloud at any point in capture or verification. The signature is a portable cryptographic artifact that any verifier — wallet, contract, custodian — can validate offline.
- Decomposed indicators, not biometric data. The signature payload contains scored indicators (consent clarity, distress level, coercion confidence). The underlying biometric features are not reconstructible from the signature. Cryptographic erasure on user request renders even the indicators unverifiable forever.
- Opt-in always, revocable always. SoM Sig is a wallet capability the user enables. The wallet works without it; we don't gate baseline functionality. Disable at any time. Re-enable at any time. No regulator can mandate it through us — we have no backdoor to enable.
- Open verification. The verification library for wallet integrations will be open-source under permissive license. The signature scheme is standard primitives —
EdDSA, hardware attestation chains, W3C VC serialization. Anyone can audit. Anyone can implement. - User policy, not provider policy. The wallet enforces policies the user configures. We don't ship "RTScale-approved" lists. We don't blocklist addresses. We don't decide what counts as suspicious. The signature reports indicators; the user's wallet policy decides what to do with them.
How SoM Sig drops into the stack you already run.
The signature is a payload, not a wallet. Hardware wallets, smart contract wallets, MPC custodians, and browser extensions each take a different integration path.
Hardware wallets · companion-app capture
Pattern 01Browser extension wallets · WebAuthn-like surface
Pattern 02Smart contract wallets · on-chain verification
Pattern 03MPC & institutional custody · threshold attestation
Pattern 04Multi-sig wallets · per-signer SoM
Pattern 05What SoM Sig actually defends — and what it doesn't.
Honest accounting. Several attack surfaces fall cleanly within the consent-provenance model. Others are partially mitigated. A few are outside the primitive entirely.
Builder questions, answered honestly.
Pulled from working sessions with wallet engineering teams, account-abstraction protocol designers, and institutional custody platforms.
No. Capture, scoring, and signing happen entirely on the user's device, inside hardware-attested secure execution (Secure Enclave, StrongBox, TPM 2.0). The signature payload contains decomposed indicators and provenance — a small cryptographic artifact — not raw frames or audio. There is no API to retrieve biometric data, even for the user themselves. Cryptographic erasure of the indicators on user request renders them mathematically unverifiable. This guarantee is contractual.
Yes, through the companion-app pattern. The hardware wallet produces the cryptographic signature, exactly as today; the companion app captures and seals the SoM signature using the device's camera and microphone. Both signatures are bound to the same transaction hash. The hardware wallet's existing security model is unchanged. Air-gapped flows work: both signatures can transfer via QR code along with the transaction payload.
No new trust party. For self-custody wallet flows, RTScale's stack runs entirely on the user's device. The verification library is open-source. The cryptographic primitives are standard (EdDSA, hardware attestation chains, W3C Verifiable Credentials). You can audit the entire path, replace any component, run without our cloud, and the system still works. The signature is portable — any verifier can validate it offline. Self-custody means you trust your hardware and your code; we don't move that line.
Quick Scan latency is ~200 ms p95 on-device — well below the latency of any network round-trip. Your wallet's existing confirmation popup time dominates. For routine transactions below user-configured thresholds, you can disable SoM entirely; for above-threshold transactions, you absorb a single Deep Scan when threshold is crossed. The policy is yours. We have integration partners doing high-frequency on-chain activity at production scale; they configure thresholds that match their flow.
Your seed phrase still recovers your wallet — SoM Sig does not replace the existing recovery flow. On a new device, you re-establish the SoM baseline (about 60 seconds of normal-state capture across a few sessions) and resume. If your policy required guardian alerts, your guardians will have records of any held transactions during the period your device was unavailable. SoM is an additional layer of consent provenance, not a replacement for seed-phrase recovery.
SoM Sig becomes one of the signature schemes the smart contract wallet accepts. The wallet's validation logic checks the SoM signature against the wallet-owner-configured policy before approving the UserOp. The bundler can be SoM-aware (validating before submission) or SoM-agnostic (passing through; on-chain validation alone). We have reference implementations for ERC-4337 against Safe and ZeroDev contracts, and we are tracking ERC-7702 closely as it stabilizes.
SoM Sig is a wallet capability the user opts into. We have no kill switch, no master key, no override path. The signatures are cryptographic; we cannot fabricate or revoke them on a government request because the verification can be performed offline by anyone with the public key infrastructure. If a regulator demanded a backdoor, the architecture makes us unable to provide one without breaking the open-source verification stack — which would be immediately detectable. We treat the absence of backdoors as load-bearing.
SoM Sig captures consent provenance at the user's device — it does not observe the on-chain payload. A Monero transaction's privacy properties are preserved; the SoM signature attests to the consent surrounding the act, not the transaction's contents. For ZK-wallet flows, the SoM signature can be included in a zero-knowledge proof of clear-consent without revealing the underlying indicators. We're collaborating with one ZK-wallet team on a reference implementation; spec link in the protocol section once it's public.
Bring your wallet. We'll wire SoM Sig in during a working session.
Sixty minutes, your codebase, our SDK. Hardware wallet companion app, browser extension signing flow, ERC-4337 module, or MPC threshold input — pick the integration pattern that matches your stack. We'll have a working end-to-end signature in your environment before the session ends. No deck.