> ## Documentation Index > Fetch the complete documentation index at: https://docs.polygon.technology/llms.txt > Use this file to discover all available pages before exploring further. # Security > How keys are secured, transactions are validated, and the wallet remains non-custodial end to end. 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](/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](/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](/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. | Component | Auditor | Date | Report | | ----------------------------- | ---------------------------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | WaaS authenticator | Quantstamp | 2024-10-01 | [PDF](https://github.com/0xsequence/waas-authenticator/blob/master/audits/quantstamp-2024-10-01.pdf) | | Authentication infrastructure | Quantstamp | 2025-12-02 | [PDF](https://github.com/0xsequence/identity-instrument/blob/master/audits/Quantstamp-Dec-2-2025.pdf) | | Wallet contracts v3 | Quantstamp | 2025-09-25 | [PDF](https://github.com/0xsequence/wallet-contracts-v3/blob/master/audits/quantstamp-audit.pdf) | | Wallet contracts v3 | ConsenSys Diligence | 2025-09-25 | [PDF](https://github.com/0xsequence/wallet-contracts-v3/blob/master/audits/consensys-audit.pdf) | | Wallet contracts v3 | Code4rena bounty competition | 2025-11-25 | [PDF](https://github.com/0xsequence/wallet-contracts-v3/blob/master/audits/code4rena-audit.pdf) ([response](https://github.com/0xsequence/wallet-contracts-v3/blob/master/audits/code4rena-audit-response.md)) |