Security

OMS wallets are built on a hardened smart wallet architecture. This page covers the key security properties relevant to fintechs and financial products building on top of it.

​

Key security: AWS Nitro Enclaves

Private key material never exists in plaintext outside of a hardware-isolated execution environment. OMS wallets use AWS Nitro Enclaves, a hardware-enforced isolation model where:

• The enclave runs in a separate memory space, invisible to the host OS.
• No SSH access, no persistent storage, no network interface (except a controlled virtual socket).
• Code running in the enclave is verified against a known measurement (EIF hash) before it can decrypt key material.
• OMS wallet operators cannot access user keys, even with root access to the host machine.

The enclave architecture is audited and its measurements are publicly published, allowing independent verification. See Wallets Infrastructure for a full description of the enclave model, attestation flow, and deployment ceremony.

​

Enclave-bound authentication

Authentication runs inside the Nitro Enclave. The enclave verifies user identity through OAuth + PKCE, OIDC, or email OTP, then binds the verified identity to a device credential keypair held by the client SDK. Every RPC is signed with that credential before it leaves the client; no OAuth secret is handled by app-layer code. The app never receives the raw OAuth token. The enclave processes it and returns only a signed attestation scoped to the app domain. Even a fully compromised app server cannot extract user credentials or reuse an attestation outside its intended scope. For the full authentication flow, credential-signing protocol, and key derivation details, see Wallets Infrastructure.

​

Merkleized wallet configuration

The wallet’s onchain state is a single Merkle root: a compact commitment to the full configuration including:

• Authorized signers (session keys, recovery keys)
• Smart session rules (explicit permissions)
• Recovery configuration

When a transaction is submitted, only the relevant Merkle branch is provided onchain. This minimizes calldata, keeps gas costs low, and means the wallet does not need to enumerate all signers; it only proves the relevant one is authorized. Cross-chain coherency: The same Merkle root governs all chains. A wallet registered on Polygon works identically on any other supported EVM chain without redeployment.

​

Guard Firewall

The Guard Firewall is an optional transaction review layer that runs before any transaction reaches the chain. It can be configured to:

• Block transactions to non-allowlisted contract addresses.
• Flag transfers exceeding configurable thresholds for review.
• Reject transactions that violate explicit session rules before they reach the relayer.

For regulated financial products, the Guard Firewall provides a programmable policy layer between your application logic and onchain execution.

​

Non-custodial guarantee

Neither OMS nor Polygon can unilaterally move user funds. The key security properties that enforce this:

• User keys are sharded using Shamir’s Secret Sharing across multiple geographically distributed remote key holders. No single entity, including the operator, holds a complete key.
• The signing enclave requires a valid attestation from the in-enclave authentication service to decrypt and use any key shard.
• Attestations are scoped to a specific app domain and expire. A compromised attestation cannot be reused by a different app or after expiry.

For depth on the Trusted Third Party council, Shamir split parameters, PCR0 measurements, and deployment ceremonies, see Wallets Infrastructure.

​

Audits

OMS Wallet relies on three audited codebases: the WaaS authenticator (which runs inside the Nitro Enclave), the authentication infrastructure that handles OIDC and OAuth flows, and the on-chain wallet contracts v3. Audit reports are published in the respective repositories and linked directly here.