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. 1Security 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. 1RouterClient 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. 1circle 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 exportsCIRCLE_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
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
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
UsecreateRemoteSigner 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
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. 1walletAddress, 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 returnedResponse 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