Skip to main content

SELAT Router SDK Signers

Choose a signing model that matches your application’s runtime, custody boundary, and deployment environment.
The SELAT Router SDK accepts a PaymentSigner when you construct RouterClient. A signer supplies the address and EIP-712 signature needed to pay a valid challenge returned through SELAT Router. The package exposes five supported creation paths: a private-key signer, a Circle Agent Wallet signer, an HTTP remote signer, a custom remote signer, and a Circle Developer-Controlled Wallet signer. 1

Choose a signer

The table below is the fastest way to select a production-appropriate option. It emphasizes where signing material lives rather than treating all signers as equivalent. 1
Security principle: Keep long-lived signing material outside browser code and untrusted client environments. Use a server-side signer boundary for production systems. 1

Private-key signer

Use a private key only when in-process key handling is appropriate, such as a short-lived local prototype. Store the value in a secret manager rather than source control, and do not expose it to the browser. 1
RouterClient also accepts a privateKey option directly. Passing an explicitly constructed signer is generally clearer because it keeps signer selection visible in application code. 1

Circle Agent Wallet signer

Use a Circle Agent Wallet signer when the application runs in a Node.js environment where the Circle CLI is available and authenticated. Install the SDK and Circle CLI package in the same application so the SDK can resolve the CLI without relying on a globally installed binary. 1
The signer invokes the local circle CLI. Before using it, complete Circle’s Agent Wallet setup and login flow, and confirm the selected wallet has an available Gateway balance on the chain used by RouterClient. 1 2

Next.js and Node deployment packaging

The SDK exports CIRCLE_AGENT_WALLET_NEXT_TRACE_INCLUDES for Next.js deployments that must include the CLI and its dependencies in the traced function output. This configuration handles packaging only; the executing environment must still have an authenticated Circle CLI session and a compatible writable runtime. 1
For a conventional managed serverless function, the local CLI and its authenticated session are normally not present. In that environment, use createHttpRemoteSigner instead of attempting to invoke a local Circle CLI. 1

HTTP remote signer for serverless workloads

createHttpRemoteSigner is the recommended path when your application runs in serverless functions, edge-adjacent application tiers, or another environment that cannot host an authenticated Circle CLI. It sends a signing request to an HTTPS service you operate and also handles Gateway owner-address resolution for smart-contract-account wallets. 1
Your signing service receives POST { address, typedData } and returns { "signature": "0x..." }. Protect this service as a signing boundary: authenticate callers, scope its authority, validate the request policy, and retain audit records appropriate for your environment. 1

Custom remote signer

Use createRemoteSigner when your application already has a signing service, hardware security module, key-management service, or custom authorization protocol. The SDK delegates all transport behavior to the supplied callback. 1
Choose createHttpRemoteSigner instead when your endpoint follows the standard HTTP contract above and you want the SDK’s additional Gateway owner-address resolution. 1

Circle Developer-Controlled Wallet signer

Use this signer when the application already signs through a Circle Developer-Controlled Wallet. Keep the API key and entity secret in a server-side secret manager; never deliver them to a frontend application. 1
The signer options also support walletAddress, blockchain, chain, memo, baseUrl, and userAgent when the wallet deployment requires explicit configuration. 1

Test the signing path

After selecting a signer, make a small paid request against a known endpoint and handle the returned Response as you would with native fetch. A wallet must have a spendable Gateway balance on the selected chain before a paid request can settle. 1
For client options, payment protocol preference, request timeouts, and error classes, see RouterClient. For an end-to-end setup, see the SDK Quickstart.

References