RelayerRegistry

​

Overview

​

Purpose

• Relayer Whitelisting: Maintain a list of trusted relayer addresses
• Access Control: Prevent unauthorized relayers from submitting transactions
• Gasless Transactions: Enable trusted relayers to submit meta-transactions for users
• Automated Fulfillment: Allow approved relayers to automatically fulfill intents

​

State Variables

mapping(address => bool) public isWhitelistedRelayer;
address[] public relayers;

• isWhitelistedRelayer: Maps relayer addresses to their whitelist status
• relayers: Array of all whitelisted relayer addresses

​

Core Functions

​

Adding Relayers

function addRelayer(address _relayer) external onlyOwner

• _relayer: Address of the relayer to whitelist

• Relayer address cannot be zero address
• Relayer must not already be whitelisted
• Only callable by owner

​

Removing Relayers

function removeRelayer(address _relayer) external onlyOwner

• _relayer: Address of the relayer to remove

• Relayer must be currently whitelisted
• Only callable by owner

​

View Functions

​

Get All Relayers

function getWhitelistedRelayers() external view returns (address[] memory)

​

Check Relayer Status

bool isWhitelisted = relayerRegistry.isWhitelistedRelayer(relayerAddress);

​

Integration with Core Contracts

​

Orchestrator

// In Orchestrator constructor
relayerRegistry = IRelayerRegistry(_relayerRegistry);

// Validation logic
if (msg.sender != intentSignaler) {
    require(
        relayerRegistry.isWhitelistedRelayer(msg.sender),
        "Caller must be intent signaler or whitelisted relayer"
    );
}

​

Configuration Updates

function setRelayerRegistry(address _relayerRegistry) external onlyOwner {
    relayerRegistry = IRelayerRegistry(_relayerRegistry);
    emit RelayerRegistryUpdated(_relayerRegistry);
}

​

Use Cases

​

Gasless Transactions

1. User signs an intent off-chain
2. Whitelisted relayer submits the transaction on-chain
3. Relayer pays gas fees
4. Relayer potentially earns fees from the intent

​

Automated Intent Fulfillment

1. Relayer monitors off-chain payment systems
2. When payment is confirmed, relayer submits proof on-chain
3. Intent is fulfilled without user needing to submit second transaction

​

Meta-Transaction Support

1. User signs message with intent to perform action
2. Relayer wraps user’s signature in actual transaction
3. Contract validates user signature and relayer authorization
4. Action executes as if user submitted directly

​

Access Control

​

Owner-Only Functions

• addRelayer(): Add relayer to whitelist
• removeRelayer(): Remove relayer from whitelist

​

View Functions

• getWhitelistedRelayers()
• isWhitelistedRelayer[address] (public mapping)

​

Events

event RelayerAdded(address indexed relayer);
event RelayerRemoved(address indexed relayer);

• Monitoring relayer whitelist changes
• Off-chain tracking of authorized relayers
• Audit trails for relayer management

​

Usage Patterns

​

Adding a Relayer

// Authorize new relayer
relayerRegistry.addRelayer(newRelayerAddress);

// Relayer can now submit transactions

​

Removing a Relayer

// Revoke relayer authorization
relayerRegistry.removeRelayer(compromisedRelayerAddress);

// Relayer can no longer submit transactions

​

Validation in Orchestrator

function fulfillIntent(bytes32 intentHash) external {
    Intent memory intent = intents[intentHash];
    
    // Allow intent owner or whitelisted relayer
    require(
        msg.sender == intent.owner || 
        relayerRegistry.isWhitelistedRelayer(msg.sender),
        "Not authorized"
    );
    
    // Process fulfillment
    // ...
}

​

Relayer Security

​

Trust Assumptions

1. Submit Valid Transactions: Only submit legitimate user requests
2. Protect User Data: Handle user signatures and data securely
3. Fair Fees: Charge reasonable fees for relaying services
4. Availability: Maintain uptime for critical operations

​

Security Considerations

1. Centralized Trust: Relayers are centrally approved by owner
2. Revocability: Malicious relayers can be removed from whitelist
3. User Consent: Users must explicitly sign transactions for relayers
4. Limited Scope: Relayers can only execute user-signed actions

​

Relayer Compromise Response

1. Owner immediately removes relayer from whitelist
2. Relayer can no longer submit new transactions
3. Existing intents are not affected
4. Monitor for any malicious activity from the compromised relayer

​

Relayer Requirements

1. Identity Verification: Know who operates the relayer
2. Security Audit: Review relayer infrastructure security
3. Reputation: Check relayer’s history and reputation
4. SLA Commitment: Ensure relayer commits to availability
5. Fee Transparency: Relayer must be transparent about fees

​

Deployment Strategy

1. Initial Deployment: Deploy registry with no relayers
2. Add Trusted Relayers: Whitelist vetted relayer addresses
3. Configure Orchestrator: Set registry address in Orchestrator
4. Monitor Activity: Track relayer submissions via events
5. Iterate: Add/remove relayers as needed

​

Related Contracts

• Orchestrator - Uses registry to validate relayer submissions
• OrchestratorV2 - Enhanced orchestrator with relayer support
• PaymentVerifierRegistry - Related registry for payment verifiers