Build
Skip to content

Overview

Embedded Wallet Architecture

Sequence Embedded Wallets are native smart contract multisig wallets. The configuration of the multisig is 2/2, where both parties are required to sign in order to submit a transaction.

Unlike the more traditional MPC architecture where the keys are first created together and then separated, Sequence WaaS keys are always kept separate and never have to be combined to sign.

On top of this core security layer, Sequence WaaS architecture offers additional protections:

  • Sequence Auth: Running in an encrypted AWS Nitro Enclave, Sequence Auth acts as the first signer and it's locked into the latest publicly audited version by Quantstamp. Sequence doesn't have the ability to access the enclave or push updates to it without Quantstamp's approval.
  • Sequence Guard: Running independently from Sequence Auth, Guard is capable of reviewing both the user's identity and intent before signing transactions.
  • OpenID Connect Compatibility: Sequence WaaS leverages established OpenID Connect providers such as Google, Apple and any other provider that follows the same protocol. Unlike any other solution on the market, WaaS also allows developers to leverage their own OIDC identifiers with these services.

Sequence Auth

Sequence Auth is an API service that runs on the AWS Nitro Enclaves platform and provides an authentication signer which contributes to the 2/2 multisig configuration per user wallet. Sequence Auth provides a simple way to add account creation, login, session management, and wallet support to your app, enabling applications to provide traditional web experiences (i.e. social login, email login, etc.) while providing access to crypto wallets to interact with smart contracts.

WaaS Configuration Key

For every new instance, a WaaS Configuration Key is used to authenticate an App or Game Client. This provides access to the blockchain through the WaaS SDK via the generated intents sent to Sequence Auth. Within a configuration key multiple Login Provider client ID's can be registered, which each individually determine the wallet addresses generated per Provider. This means, if a client ID for a Login Provider (e.g. Google or Apple) is shared across instances, users using the same Login Provider with authentication credentials will yield the same address.

Wallet Private Keys

Wallet private keys are stored encrypted using a split responsibility strategy between Sequence and Quantstamp:

  1. Sequence is able to access only the encrypted blobs stored in the database with no means of decryption.
  2. Quantstamp owns and operates the KMS (AWS hardware security module) used to encrypt the wallet key data. They have no way to export the key material and no access to the encrypted data itself.

Waas Enclave

The WaaS Enclave is the only entity able to use the encrypted wallet data. Its security is guaranteed by:

  1. The AWS Nitro hypervisor generates and signs a cryptographic attestation based on the actually running enclave code. The document includes a PCR0 (a hash of the enclave code) signed by the Amazon Public Key Infrastructure.
  2. The KMS operated by the Trusted Third Party specifies a policy that only allows access to the cryptographic operations if the attestation is valid and the PCR0 hash of the enclave matches the expected value. This means that any - even the smallest - change to the enclave will result in a different attestation and PCR0 hash, effectively invalidating it.
  3. The enclave code is open source and anyone may audit it and verify that the service uses the exact audited version of the source code. Learn more about verification.

Sequence Auth source code is publicly available and independently audited, and the safeguards described above ensure it cannot be tampered with by any party.

Sequence Guard

Sequence Guard is a service hosted by Sequence and is the other key of the wallets which contributes to the 2/2 configuration per wallet. It's meant to be another line of defense, verifying not only user's identity but also their intent. It achieves this in two different ways:

1 - Limits and allowlists: you can (from the development dashboard) configure what kind of actions are allowed, this means that the guard will only sign transactions within these constraints. For example, you can define that only NFT contract X can be called, and the guard will enforce that no other transactions can take place.

2 - Authenticating the user: the Sequence Guard will authenticate the user independently of Sequence Auth, it performs this action either by using a 3rd party OAuth 2.0 id token (from Meta, Google, X, etc.) or by directly communicating with the user via email/phone number with an OTP code. The direct communication is not always required and, when it does happen, it's seamless and branded with your project details.

Threat model

With these safeguards in place wallets are safe against the following scenarios:

  1. Sequence.app backend is compromised, or guard keys are leaked: in this scenario, the user's identity must still be verified by Sequence Auth.

  2. Sequence Auth is compromised: in this scenario the Sequence Guard protects the wallets, because it independently authenticates the user, an attacker in this scenario wouldn't be able to access any wallets.

The model also provides partial protection against the scenario:

  1. Partner frontend is compromised, or MITM on the partner side: If an attacker were to be able to vulnerate the frontend of the partner, it could gain access to wallets at the time of login, but it cannot gain access to wallets of users who are currently inactive. This means that recovery from such a scenario is possible, with limited damage.

Simplified Data Flow

Below we illustrate the data flow of a common use case such as signing a transaction via embedded wallets.

data-flow-architecture

1. Generation of the Intent

The user interacts with the client to "do something" that requires an action on behalf of the wallet (i.e. send some USDC or call a contract method).

The client asks the WaaS SDK to generate an intent for such an action; this intent is signed with the session keys of the client. This session key is a generated key that is only valid while that OAuth session is valid. Every intent sent to the WaaS backend is first signed by this session key to validate that there is an active, authenticated session on the user side.

2. SDK Forwards Intent to Sequence Auth

The intent and its corresponding signature are sent to the Sequence Auth service running on an AWS Nitro Enclave. Sequence Auth asks WaaS API to build a transaction for the given intent and then validates that the transaction does not deviate from the original intent. On successful validation, Sequence Auth signs the transaction and forwards the transaction, intent, and signature to the WaaS API.

4. WaaS API Collects Signature from Sequence Guard

WaaS API receives a "half-signed" transaction request, alongside an intent that has been signed by the client. It needs to collect one more signature before being able to relay the transaction, so it calls Sequence Guard.

5. Sequence Guard Authenticates the User

Sequence Guard receives a signature request for a given wallet. It verifies that the intent exists, corresponds to the transaction, and has been signed by a valid session. If everything is correct, it signs the transaction.

6. Relay and Transaction Receipt

WaaS API relays the transaction and waits for the receipt. The resulting txHash is piped back to the client.