Architecture

Technical overview of how Brtr Protocol is built.

System Overview

Core Components

BrtrOTCV1 Smart Contract

The main contract deployed on each supported chain. Handles:

• Order creation — Sellers deposit tokens, set payment options
• Token escrow — Secure custody until trade completes
• Same-chain settlement — Atomic swaps in single transaction
• Cross-chain coordination — LayerZero message handling
• Fee collection — Protocol fee distribution

LayerZero Integration

Brtr inherits from LayerZero's OApp (Omnichain Application) standard:

contract BrtrOTCV1 is OApp, Ownable {
    // Cross-chain message types
    uint8 constant MSG_TYPE_FILL_INITIATE = 1;
    uint8 constant MSG_TYPE_FILL_CONFIRMATION = 2;
    uint8 constant MSG_TYPE_FILL_FINALIZATION = 3;
    // ...
}

Key features:

• Peer verification — Only accepts messages from known contracts
• Gas drop — Native token forwarding for return messages
• Secure messaging — DVN (Decentralized Verifier Network) validation

Frontend

React-based web application:

• Wallet connection (RainbowKit/wagmi)
• Multi-chain support
• Real-time order updates
• Transaction tracking

Indexer

Event indexing service:

• Listens to contract events across all chains
• Aggregates order data for fast queries
• Powers the marketplace discovery UI

Security Model

Token Escrow

All tokens are held in smart contracts:

1. Seller creates order → Tokens transferred to contract
2. Buyer fills order → Payment transferred to contract
3. Trade completes → Tokens released to respective parties

No tokens are ever held by Brtr team or any intermediary.

Atomicity

For cross-chain trades, the 3-message protocol ensures either:

• Both parties receive tokens (success)
• Both parties keep original tokens (failure + recovery)

Access Control

// Only contract owner can:
- Set fee rates (capped at 10%)
- Add/remove supported chains
- Emergency pause (if needed)
- Update fee collector address
 
// Anyone can:
- Create orders
- Fill orders
- Cancel own orders
- Recover stuck funds (after timeout)

State Management

Order States

enum OrderStatus {
    Open,                  // Active, accepting fills
    AwaitingConfirmation,  // Cross-chain fill started
    AwaitingFinalization,  // Waiting for final message
    Completed,             // Successfully traded
    Cancelled              // Cancelled by seller
}

Pending Fill States

For cross-chain trades, buyer-side tracking:

enum PendingFillStatus {
    None,               // No pending fill
    Initiated,          // Awaiting confirmation
    ConfirmationReceived, // Confirmed, awaiting finalization
    Completed           // Done
}

Gas Optimization

Gas Drop Mechanism

Cross-chain fills include native tokens for subsequent messages:

// Calculate gas for finalization
uint128 finalizationDrop = quoteFinalizationGasFee(dstEid);
 
// Calculate gas for confirmation (includes finalization)
uint128 confirmationDrop = quoteConfirmationGasFee(dstEid);
 
// Apply 9x buffer for safety
uint128 buffered = amount * 90_000 / 10_000;

Quote Functions

// Get total cost before filling
function quoteFee(
    uint32 dstEid,
    bytes32 orderId,
    address filler,
    // ...
) public view returns (MessagingFee memory fee)

Recovery Mechanisms

Built-in safeguards for edge cases:

Deployment

Each chain deployment is independent but interconnected:

Base Sepo       ←→ LayerZero ←→ OP Sepo
     ↓                              ↓
Monad Testnet   ←→ LayerZero ←→ MegaETH

All contracts are registered as "peers" in LayerZero, enabling secure cross-chain communication.

Related

• LayerZero Integration — Messaging details
• Contract Addresses — Deployed addresses
• Cross-Chain Trades — User perspective