How a signature is protected

Two things protect an account. Where the key lives, and what has to be true before it signs.

Keys never touch the device

Signing keys are generated and held inside an attested Trusted Execution Environment. Nothing on the user’s device holds key material, so a compromised browser or a compromised laptop has nothing to steal. There are two ways a signature is then completed:

Squid Mode is the one where key material is never assembled in a single place. Our enclave holds one part and Ika’s validators hold the other, and they are never combined, so no single operator can produce a signature for the account. In Standard, the key is held whole inside the enclave and the protection is the attestation plus the authorization gate below. Both are protected self-custody. They are not the same trust model, and this page never claims they are.

Every signature is gated

Custody is only half of it. Before anything is signed:

• Exact bytes are verified first - the transaction that is reviewed is the transaction that gets signed
• The Policy Engine decides - spending limits, risk thresholds, and 2FA rules apply regardless of what the client asks for
• Approval is single-use - bound to one user, one transaction digest, and one operation, then burned before signing
• The signer checks again - the key manager independently re-verifies before producing a signature

Advanced protection

• Blind signing resistance. Transaction simulation runs server-side, so the check does not depend on what the interface drew
• Malware resistance. No device-side key, and a compromised client cannot approve outside policy
• Policy-based controls. Configurable spending limits and authorization rules

Audits

Audited by Cure53 , Hexens , Least Authority  and Halborn , with security consulting from Anderson Software  and Distrust .

See Audits & Security Partners.