Skip to main content
Gateway supports programmable authorization through ERC-1271. Smart contracts and smart contract accounts (SCAs) can authorize transfers directly with their own validation logic. You can access a unified USDC balance from a multisig, role-based permission system, passkey, administrator key, or any other deterministic authorization model.

​
What ERC-1271 enables

An Externally Owned Account (EOA) proves authorization with a cryptographic signature from its associated private key. Because smart contracts don’t have a private key, they can’t produce signatures in the same way. ERC-1271 solves this with a standard function isValidSignature(bytes32 hash, bytes signature) that contracts can implement to decide whether a signature is valid. Verifiers call the validation function instead of recovering the cryptographic signer directly. This enables more complex authorization logic that can be programmed into the smart contract. Common examples include:
  • Multisig wallets that require a threshold of signers
  • Role-based or policy-based permission systems
  • Passkey-based smart accounts
  • Contracts that enforce allowlists, spending limits, or compliance checks before approving an action
Gateway can validate ERC-1271 signatures directly, so you don’t need to add a delegate or redesign how your application authorizes transfers.

​
How ERC-1271 validation works

1

Submit the burn intent

You submit a burn intent to the Gateway /v1/transfer endpoint with the contractSigner: true flag and the contract’s signature.
2

Validate the signature in a TEE

Gateway routes the request to a validation service, deployed as an AWS Nitro Enclave that validates the signature at request time. The enclave queries multiple independent blockchain RPC providers and simulates the contract’s isValidSignature response against a recent target block height.
3

Reach RPC quorum

If a quorum of RPCs (at least 2 of 3) agree that the signature is valid, the validation service signs off on the request and the Gateway API returns the attestation as usual.
4

Complete the burn

When the attestation is used, Gateway performs the burn using the validation service’s signature. The Gateway Wallet contract recognizes the validation service signature and completes burns validated this way.
From your application’s perspective, the request and response are the same as an EOA transfer. The Trusted Execution Environment (TEE) and RPC quorum are internal mechanisms that let Gateway extend its offchain validation guarantee to contract signatures.

​
Security model

ERC-1271 validation runs inside a Trusted Execution Environment (TEE) so that Circle can’t unilaterally control which signatures are accepted. The security model relies on three components.

​
Trusted execution environment (TEE)

A Trusted Execution Environment (TEE) is an isolated hardware enclave that runs code in a secure, tamper-proof environment. Gateway uses an AWS Nitro Enclave to validate the ERC-1271 signature, query the RPC quorum, and sign the burn intent with the enclave’s private key. The enclave’s signing key is protected by AWS Key Management Service (KMS) with attestation-based access policies. Only the audited enclave image can access the key. Circle can’t access the signing key or extract it outside the enclave.

​
Independent RPC quorum

The enclave validates each signature against a quorum of independent blockchain RPC providers. Circle can’t independently modify the quorum logic or the set of RPC providers the enclave uses, because both are fixed in the audited enclave image. In particular, Circle can’t make its own RPCs the sole validator of a request: a request is only accepted when a quorum of the enclave’s independent providers agree that the signature is valid.

​
Cryptographic attestations

AWS Nitro Enclaves produce cryptographic attestation documents that prove the enclave is running a specific, audited code image. These attestations can be independently verified, providing transparency into the validation process.

​
Opting into ERC-1271 validation

Requests that opt into ERC-1271 validation include contractSigner: true alongside the burn intent and signature in each item of the /v1/transfer payload:
The burn intent’s sourceSigner is the address of the signing contract, and the signature is produced by that contract’s ERC-1271 authorization logic. When contractSigner is omitted or false, Gateway validates the signature as a standard EOA signature. For a complete walkthrough that signs a burn intent with a Circle smart contract account, see How-to: Transfer USDC from a smart contract account.

​
Limitations and considerations

  • EVM-only: ERC-1271 validation is supported only on EVM blockchains.
  • Read-only validation: The validation service simulates isValidSignature offchain, so authorization logic that modifies onchain state during validation isn’t supported.
  • Timing: The validation service ensures that simulation is done against recent blocks. The validation service can validate signatures using blocks up to 5 minutes old. This means that it may take up to 5 minutes for key rotation or revocation transactions to apply.
  • RPC trust assumptions: Gateway uses a quorum of multiple node operators on each request to mitigate incorrect responses, but Gateway can’t guarantee that each RPC performed the validation correctly or that an RPC’s network security wasn’t compromised.
  • You remain responsible for your signing setup: As with EOAs, using Gateway with ERC-1271 doesn’t guarantee that your contract’s authorization logic is secure. Depositors using insecure ERC-1271 implementations can have their balances drained. Be sure to audit and secure your signing setup.
Nanopayments, part of Circle Agent Stack, isn’t available through ERC-1271. Nanopayment burn intents are batched and submitted through ERC-3009 requests, which use a different validation path.