> ## Documentation Index
> Fetch the complete documentation index at: https://developers.circle.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ERC-1271 programmable authorization

> How Gateway validates smart contract signatures with ERC-1271, including the offchain TEE and RPC quorum security model, usage, and limitations.

Gateway supports programmable authorization through
[ERC-1271](https://eips.ethereum.org/EIPS/eip-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

<Steps>
  <Step title="Submit the burn intent">
    You submit a burn intent to the Gateway
    [`/v1/transfer`](/api-reference/gateway/all/create-transfer-attestation)
    endpoint with the `contractSigner: true` flag and the contract's signature.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Complete the burn">
    When the attestation is used, Gateway performs the burn using the validation
    service's signature. The [Gateway Wallet contract](/gateway/references/technical-guide#gateway-wallet-contracts) recognizes the
    validation service signature and completes burns validated this way.
  </Step>
</Steps>

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`](/api-reference/gateway/all/create-transfer-attestation)
payload:

```json theme={null}
[
  {
    "burnIntent": { "...": "..." },
    "signature": "0x...",
    "contractSigner": true
  }
]
```

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](/gateway/howtos/transfer-with-erc-1271).

## 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.

<Note>
  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.
</Note>