Model-written summary with sentence-level citations. Each sentence is followed by the verbatim source text it was checked against; sentences without a qualifying excerpt were removed.

Research target 1

Requested topic (unverified): “Does Circle Gateway Nanopayments/x402 batch settlement support ERC-1271 contract wallets for this citation-toll research business on Arc mainnet?”

Gateway Nanopayments and x402 batch settlement require EOA signatures and do not support ERC-1271. [2] Source text: “Gateway Nanopayments and x402 batch settlement require EOA signatures and do not support ERC-1271.”

Research target 2

Requested topic (unverified): “What supported EOA Nanopayments payment flow takes the business from a Gateway deposit through buyer authorization, seller delivery and batched settlement?”

A buyer deposits USDC into a Gateway Wallet contract as a one-time onchain transaction. [2] Source text: “A buyer deposits USDC into a Gateway Wallet contract (one-time onchain transaction).”

A buyer requests a paid resource from a seller's API. [2] Source text: “A buyer requests a paid resource from a seller’s API.”

The seller responds with 402 Payment Required and payment details. [2] Source text: “The seller responds with 402 Payment Required and payment details.”

The buyer signs an EIP-3009 payment authorization offchain at zero gas. [2] Source text: “The buyer signs an EIP-3009 payment authorization (offchain, zero gas).”

The buyer retries the request with the signed authorization attached. [2] Source text: “The buyer retries the request with the signed authorization attached.”

The seller verifies the signature and serves the resource immediately. [2] Source text: “The seller verifies the signature and serves the resource immediately.”

Gateway collects authorizations and settles them in batches onchain, crediting the seller's Gateway balance. [2] Source text: “Gateway collects authorizations and settles them in batches onchain, crediting the seller’s Gateway balance.”

Research target 3

Requested topic (unverified): “What standard Gateway transfer flow supports ERC-1271 contract wallets, and how does it differ from Nanopayments?”

You submit a burn intent to the Gateway /v1/transfer endpoint with the contractSigner: true flag and the contract's signature. [1] Source text: “You submit a burn intent to the Gateway /v1/transfer endpoint with the contractSigner: true flag and the contract’s signature.”

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. [1] Source text: “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. [1] Source text: “When contractSigner is omitted or false, Gateway validates the signature as a standard EOA signature.”

Gateway routes the request to a validation service, deployed as an AWS Nitro Enclave that validates the signature at request time. [1] Source text: “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. [1] Source text: “The enclave queries multiple independent blockchain RPC providers and simulates the contract’s isValidSignature response against a recent target block height.”

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. [1] Source text: “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.”

When the attestation is used, Gateway performs the burn using the validation service's signature. [1] Source text: “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. [1] Source text: “The Gateway Wallet contract recognizes the validation service signature and completes burns validated this way.”

Nanopayment burn intents are batched and submitted through ERC-3009 requests, which use a different validation path. [1] Source text: “Nanopayment burn intents are batched and submitted through ERC-3009 requests, which use a different validation path.”

Research target 4

Requested topic (unverified): “What current authorization, revocation-timing and validation-trust limitations apply to the ERC-1271 Gateway alternative?”

EVM-only: ERC-1271 validation is supported only on EVM blockchains. [1] Source text: “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. [1] Source text: “Read-only validation: The validation service simulates isValidSignature offchain, so authorization logic that modifies onchain state during validation isn’t supported.”

The validation service can validate signatures using blocks up to 5 minutes old. [1] Source text: “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. [1] Source text: “This means that it may take up to 5 minutes for key rotation or revocation transactions to apply.”

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. [1] Source text: “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.”

The enclave's signing key is protected by AWS Key Management Service (KMS) with attestation-based access policies. [1] Source text: “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. [1] Source text: “Only the audited enclave image can access the key.”

These attestations can be independently verified, providing transparency into the validation process. [1] Source text: “These attestations can be independently verified, providing transparency into the validation process.”

Depositors using insecure ERC-1271 implementations can have their balances drained. [1] Source text: “Depositors using insecure ERC-1271 implementations can have their balances drained.”

Research target 5

Requested topic (unverified): “What concrete acceptance checks should establish the correct Arc mainnet profile and wallet/payment rail, bounded authorization, genuine settlement and successful research delivery?”

The Arc network table lists Chain ID 5042, Currency USDC, and Explorer explorer.arc.io. [3] Source text: “| Parameter | Value | | :- | :- | | Chain ID | ​5042​ | | Currency | USDC | | Explorer | [explorer.arc.io](https://explorer.arc.io) |”

The Gateway table lists Arc domain 26, mainnet ​arc​, and testnet ​arcTestnet​. [4] Source text: “| Blockchain | Domain | Mainnet | Testnet | | - | - | - | - | | Arbitrum | 3 | ​arbitrum​ | ​arbitrumSepolia​ | | Arc | 26 | ​arc​ | ​arcTestnet​ |”

Common ERC-1271 examples include contracts enforcing allowlists, spending limits, or compliance checks before approving an action. [1] Source text: “Contracts that enforce allowlists, spending limits, or compliance checks before approving an action”

Summary sentences are model-written and model-checked, not independently verified; they claim no more than their excerpts and are not a complete synthesis. Excerpts establish source grounding, not that a source is correct. Source statements may be wrong or conflicting. Payment states remain in the separate receipt.

Proposed acceptance checks (inferences; not executed)

These are application checks inferred from the cited documented mechanisms, not vendor test procedures or evidence of a successful deployment. The source-backed premises appear above.

- Arc profile: compare the actual chain ID, currency and explorer with 5042, USDC and explorer.arc.io; compare the Gateway network/domain with mainnet arc/26, keeping arcTestnet separate. [3] [4]

- Wallet and rail: test Nanopayments with an EOA signer and reject ERC-1271 on that rail; for the separate contract-wallet transfer route, inspect /v1/transfer, contractSigner: true and the contract-address sourceSigner. [2] [1]

- Bounded authorization: audit the ERC-1271 policy and exercise allowed/disallowed actions against its configured allowlist and spending limit before approval. The supplied excerpts give no numeric cap, nonce, expiry or complete EOA authorization-field specification; obtain and approve those values before executing an authorization test. [1] [2]

- Contract validation: inspect the available attestation and burn evidence against request-time Nitro/isValidSignature validation and the documented RPC quorum; preserve EVM-only/read-only scope and the up-to-five-minute rotation/revocation assumption. Independently verify available enclave attestations; quorum mitigates RPC errors but does not guarantee each provider is correct or uncompromised. The excerpts do not supply a per-request RPC audit interface. [1]

- Genuine settlement: retain onchain batch-settlement evidence and verify the seller's Gateway balance credit. Keep immediate resource delivery separate from later settlement; a signed authorization or HTTP response alone is not this proposed settlement check. No real settlement is certified here. [2]

- Research delivery: exercise paid request → 402 details → EIP-3009 signature → signed retry → seller verification and immediate resource delivery; then inspect the returned research answer and its citations against all five requested targets. The research-content criterion is an application inference, and these checks have not been run. [2]

Arc-specific Gateway/USDC contract addresses, deployment readiness and executable authorization values are not established by these selected excerpts. Keep them unresolved until separately verified; no addresses, amounts, nonces or deadlines are invented here.

Requested evidence gaps from the model assessment

The requested details below remain unverified; they are not established conclusions.

Research target 1: - No citation-toll-specific business configuration or Arc-specific Nanopayments acceptance procedure is supplied.

Research target 2: - No citation-toll-specific seller middleware, pricing, or delivery verification details are supplied.

Research target 3: - No Arc-specific standard Gateway transfer example or contract address is supplied.

Research target 4: - No Arc-specific revocation timing or Arc-specific RPC quorum details are supplied.

Research target 5: - No concrete Arc mainnet contract addresses, Gateway Wallet address, USDC address, or Arc-specific deployment checklist is supplied. - No citation-toll-specific acceptance test, research-delivery verification procedure, or bounded-authorization test parameters are supplied. - No explicit Arc mainnet Nanopayments or ERC-1271 end-to-end acceptance checklist is supplied.