The @abstraxn/relayer package empowers your dApp to transform user intent into on-chain execution—gaslessly, securely, and with real-time updates.

Installation

You can install our SDK by running the following command in your terminal:

Setup & Configuration

To obtain the Relayer URL and API Key: To begin, you’ll need a Relayer URL and API Key. Retrieve these from your Abstraxn Dashboard:
  • Visit https://dashboard.abstraxn.com/
  • Log in or sign up
  • Go to Apps → click Create New App → enter name, chain, description
  • Within the app, navigate to Relayer → click Add Relayer, assign a name, select app
  • Click View Details → copy your Relayer URL and API Key
⚠️ Warning: Keep your API key secret. Store it in environment variables on the server side — never embed it into public client code.

Basic Integration (Node / Server)

buildRelayerTx vs buildRelayerTxEIP712

Both methods encode your contract call, read getNonce(userAddress), sign the meta-tx, and return the same payload shape for sendRelayerTx. The only difference is how the user signs.
If you pick the wrong method, executeMetaTransaction will revert with an invalid signature. Check your contract’s meta-tx verification logic — or try buildRelayerTxEIP712 first if unsure.
Rule of thumb:
  • Abstraxn-deployed / EIP-712 meta-tx contracts → buildRelayerTxEIP712
  • Legacy contracts expecting signMessage on keccak256(nonce, target, chainId, data)buildRelayerTx
Your signer must support the chosen method:
  • buildRelayerTxEIP712 requires signTypedData (or _signTypedData)
  • buildRelayerTx requires signMessage
For backend agents using an Abstraxn Server Wallet, see Gasless Relayer with Server Wallet — supports both build methods via createRelayerSigner().

Real-Time WebSocket Integration

Real-time updates (v0.1.5+). Server or client can subscribe to live events for instant UX.
Status flow moves: initiated → pending → confirmed / failed / rejected

Safe Transaction Execution

Execute Safe transactions with multiple owners using the Relayer SDK. This example demonstrates how to build a Safe transaction, collect signatures from multiple owners, and execute it through the relayer with real-time WebSocket updates.

Key Components

  • Safe Transaction Building: Creates a Safe transaction with the required parameters including nonce, target address, and operation type
  • Multi-Owner Signing: Collects EIP-712 signatures from multiple Safe owners
  • Signature Sorting: Sorts signatures by signer address (required by Safe protocol)
  • Relayer Execution: Uses sendSafeRelayerTxWithRealTimeUpdates to execute the transaction through the relayer
  • Real-Time Updates: WebSocket events provide instant feedback on transaction status
⚠️ Security: Never expose private keys in client-side code. This example is for demonstration purposes. In production, handle signing on the server side or use secure wallet connections.
💡 Configuration: Make sure to set the isSafeTx: true flag in the relayer configuration when working with Safe transactions. This ensures the relayer properly handles Safe-specific transaction formats.

Wallet Whitelist (v1.1.0+)

Restrict which wallet addresses can use your relayer. Useful when only specific user wallets or server wallets should be allowed to submit gasless transactions.
v1.2.0+: setWalletWhitelist adds addresses (does not replace the full list). Use removeWalletWhitelist to remove specific addresses. Requires @abstraxn/relayer@1.2.0+.

How it works

When isWalletWhitelistEnabled is false (default), nothing changes — all wallets behave as today. When enabled, only wallets in whitelistedWallets can relay. The check uses the wallet address decoded from signed transaction calldata (not a spoofable request field).

SDK usage (server-side)

Errors

If whitelist is ON and the wallet is not allowed:
HTTP 400 — returned before gas estimation, same shape as other relayer policy failures. Mutation errors from setWalletWhitelist / removeWalletWhitelist (also HTTP 400, thrown in the SDK): If only some addresses in the array are duplicates (add) or missing (remove), the operation succeeds for the rest.
Run getWalletWhitelist, setWalletWhitelist, and removeWalletWhitelist from your backend only. Your relayer URL must include the API key. Never call these from public client-side code.
Enable the toggle under Policies → Whitelist Wallets, then add addresses there or via setWalletWhitelist. View and remove wallets under Whitelisted Wallets or via removeWalletWhitelist from your backend.

API Reference

  • new Relayer (options)
    • options.relayerUrl: string (required)
    • options.apiKey: string (required)
    • options.chainId: number | ChainId
    • options.signer (ethers/web3 signer)
    • options.provider (ethers/web3 provider)
    • options.webSocket?: { enabled: boolean, autoConnect?: boolean, reconnection?: boolean }
  • buildRelayerTx(params) → EIP-191 personal-sign meta-tx (legacy / custom contracts)
  • buildRelayerTxEIP712(params) → EIP-712 typed-data meta-tx (most Abstraxn contracts)
  • sendRelayerTx(payload) → submit prepared payload to relayer service
  • sendRelayerTxWithRealTimeUpdates(payloadWithWsOptions) → submit + subscribe to WS updates
  • getRelayerTxStatus(transactionId) → poll current state
  • getWalletWhitelist(){ isWalletWhitelistEnabled, whitelistedWallets } (v1.1.0+, server-side)
  • setWalletWhitelist(walletAddresses: string[]) → add wallets to whitelist (v1.2.0+, server-side; queued async)
  • removeWalletWhitelist(walletAddresses: string[]) → remove specific wallets from whitelist (v1.2.0+, server-side; queued async)
  • subscribeToTransaction(transactionId, events) → register handlers for updates
  • unsubscribeFromTransaction(transactionId)
  • connectWebSocket() / disconnectWebSocket() / isWebSocketConnected()

Polling vs Real-Time — When to use which?


Integrations & Best Practices

  • Server-side relay orchestration: Keep API keys and critical signing on the server.
  • Intent validation: Validate user intent before creating relayer payloads. Agents should sanitize and verify prior to send.
  • Retries & idempotency: Implement idempotency keys / dedupe when re-sending in case of network issues.
  • Fallbacks: If WebSocket connectivity fails, gracefully fallback to polling.
  • Monitoring: Log transactionId, status, and relayer response codes for observability.

Security Notes

  • Never expose apiKey in client-side code.
  • Use short-lived server tokens and rotate keys when possible.
  • Validate contract ABI and method inputs to avoid unintended on-chain calls.
  • Enforce authorization: ensure only approved apps/users can request relayer submits.

Troubleshooting

Q: sendRelayerTx returns an error / 4xx or 5xx - Verify relayerUrl and apiKey are correct. - Check server time skew (if signatures used). - Inspect payload (ABI, method, args) for mismatches. Q: WebSocket won’t connect - Ensure your environment allows outgoing WS connections. - Check CORS / firewall rules. - Confirm webSocket.enabled and autoConnect flags are set. Q: Transactions stuck in pending - Check blockchain network congestion and relayer health page (dashboard). - Verify gas estimation and paymaster configuration if used.

Quickstart Checklist

  • Create an App on dashboard → Add Relayer → copy Relayer URL + API Key
  • Install @abstraxn/relayer in your server environment
  • Instantiate Relayer with secure credentials
  • buildRelayerTxEIP712() or buildRelayerTx()sendRelayerTx() or sendRelayerTxWithRealTimeUpdates()
  • (Optional) Enable wallet whitelist in Dashboard → add server wallets with setWalletWhitelist() from backend
  • Monitor via getRelayerTxStatus() or WebSocket events
  • Integrate with Smart Accounts, Paymaster, Bundler for full agent flows

TL;DR

The @abstraxn/relayer SDK enables agent-driven, gasless on-chain execution with both polling and real-time capabilities. Keep keys server-side, validate intent, and prefer WebSocket for best UX.