rrelayer

rrelayer is a high-performance blockchain transaction relay service for EVM-compatible networks. It abstracts complex blockchain interactions into REST API calls, handling:

• Transaction Management: Relaying, signing, fee estimation, nonce management, and status monitoring.
• Security & Permissions: Support for multiple signing providers (AWS KMS, Fireblocks, Turnkey, etc.), allowlists for addresses/contracts, and API keys with restricted access.
• Operational Automation: Automatic top-ups (with Safe support), gas bump block configuration, and webhooks for status notifications.
• Reliability: Rate limiting, transaction/signing history (audit logs), and high-frequency queuing for batch processing.

rrelayer is a high-performance, open-source blockchain transaction relay service written in Rust. It is designed to simplify blockchain interactions by transforming complex operations into simple REST API calls.

Key benefits include:

• Eliminates Wallet Management: No need for applications to manage private keys, transaction queuing, or nonce management.
• Scalable Infrastructure: Designed for production-ready Web3 applications.
• Config-Driven: Most features and network settings are managed via a rrelayer.yaml file.
• Extensible: Supports any EVM-compatible network by simply configuring the RPC endpoint and Chain ID.

rrelayer is a high-performance blockchain transaction relay service written in Rust, designed for EVM-compatible networks. It abstracts complex blockchain operations into simple REST API calls, allowing developers to focus on business logic rather than managing wallets, gas optimization, transaction queuing, or nonce management.

Key features include:

• Transaction Relay: Send transactions via REST APIs.
• Message Signing: Support for various signing providers.
• Automated Gas Management: Handles gas optimization automatically.
• Real-time Monitoring: Accessible through intuitive APIs.
• Enterprise Wallet Infrastructure: Supports secure signing providers such as:
  • AWS KMS (Hardware Security Modules)
  • Turnkey (Self-custody solutions)
  • Privy (Managed wallets)
  • AWS Secrets Manager
  • GCP Secret Manager
  • Raw mnemonic development setups.

The rrelayer SDK provides a high-performance interface for interacting with EVM-compatible networks by transforming complex blockchain interactions into simple calls.

Key capabilities include:

• Transaction Management: Relaying, signing, fee estimation, nonce management, and status monitoring.
• Security & Permissions: Support for multiple signing providers (AWS KMS, Fireblocks, Privy, etc.), allowlists for addresses/contracts, and API keys with restricted access.
• Automation: Automated gas top-ups, configurable gas bump blocks, and webhooks for status notifications.
• Observability: Deep audit logs for transaction and signing history.
• Scalability: Built-in rate limiting and configurable network policies via rrelayer.yaml.

When fetching paginated data (like allowlists), the SDK returns a PagingResult<T> object. This object contains the requested items and optional context for navigating through pages.

• items: An array of the requested type T.
• next: A PagingContext object containing the limit and offset for the next page, if available.
• previous: A PagingContext object containing the limit and offset for the previous page, if available.

PagingContext consists of:

• limit: The number of items per page.
• offset: The starting position of the current page.

export interface PagingContext {
  limit: number;
  offset: number;
}

export interface PagingResult<T> {
  items: T[];
  next?: PagingContext;
  previous?: PagingContext;
}

When a transaction is submitted, rrelayer validates the to address against the configured allowlist. If the address is not permitted, the transaction is rejected with a 403 FORBIDDEN error.

Error Response Format:

{
  "error": "Recipient address not in allowlist",
  "code": "FORBIDDEN",
  "details": {
    "recipient": "0xunauthorized1234567890abcdef1234567890abcdef",
    "allowlistEnabled": true
  }
}

All signatures returned by the Signing API use the standard Ethereum format consisting of three components:

To convert these components into a single hex string for use in Ethereum libraries, use the following logic:

function signatureToHex(signature) {
  const r = signature.r.slice(2); // Remove 0x prefix
  const s = signature.s.slice(2); // Remove 0x prefix
  const v = signature.v.toString(16).padStart(2, '0');
  return '0x' + r + s + v;
}

The allowlist field (optional) defines a list of contract addresses that a relayer is permitted to interact with.

• If allowlist is set, the relayer will only be allowed to send transactions and signed typed data to the addresses specified in the list.
• If allowlist is omitted, the relayer can send transactions to any address when triggered.

permissions:
  - relayers:
      - "0x1c09df15fb12656420033eb58067ec9406ef0e26"
    allowlist:
      - "0x70997970C51812dc3A010C7d01b50e0d17dc79C8"
      - "0xcfe267de230a234c5937f18f239617b7038ec271"

ERC-2771 enables meta-transactions by allowing smart contracts to trust a specific forwarder contract. The forwarder verifies a user's signature and appends the original sender's address to the call data, allowing a relayer to pay for gas.

Workflow with rrelayer:

1. User signs meta-transaction: The user signs a message containing the desired function call.
2. Send to backend: The signed meta-transaction is sent to your backend API.
3. Backend submits via rrelayer: Your backend uses the rrelayer-ts SDK to send the transaction to the trusted forwarder.
4. Forwarder verifies and forwards: The forwarder verifies the signature and executes the call on the target contract.

The PKCS#11 provider manages keys automatically on the HSM using a namespacing strategy to prevent conflicts and cross-chain replay attacks:

1. On-demand Generation: secp256k1 key pairs are generated on the HSM when first accessed for a specific wallet index and chain ID.
2. Namespacing: Keys are tagged with a unique label: rrelayer-{identity}-wallet-{chain_id}-{wallet_index}.
3. Address Derivation: Ethereum addresses are derived using Keccak256 hashing of the public key.
4. Caching: The provider maintains a cache mapping wallet indices, chain IDs, and HSM key handles for efficiency.