Orchid Protocol Integration

Orchid Protocol Integration

Orchid is a decentralized VPN network where users pay for bandwidth with probabilistic nanopayment tickets (nanopayments), and providers sell bandwidth for OXT tokens. Technically this is not just VPN with blockchain payment—it is a system of probabilistic micropayments applied to network traffic.

The reason this is interesting from an engineering perspective: classical micropayments per data packet kill performance—on-chain transaction per 100KB bandwidth is not viable. Orchid solves this via probabilistic tickets: client sends ticket with face value $1, which with 1% probability pays out $100. Expected value of ticket is $1. Provider accepts tickets as payment, occasionally getting a winning one.

Orchid Nanopayments Architecture

Lottery Contract

Orchid Lottery contract (Ethereum mainnet + several L2s) manages provider deposit/withdrawal and ticket verification.

// Simplified Orchid Lottery scheme
contract OrchidLottery {
    struct Pot {
        uint128 amount;    // main deposit (stake)
        uint128 escrow;    // locked for pending tix
    }
    
    mapping(address => mapping(address => Pot)) public pots; // sender → token → pot
    
    // Client deposits OXT as collateral
    function push(address token, uint128 amount, uint128 escrow) external;
    
    // Provider claims winning ticket
    function grab(
        uint256 secret,   // provider secret (revealed on claim)
        bytes32 hash,     // hash(secret) — known from ticket
        address payable target,
        uint256 nonce,    // replay protection
        uint256 ratio,    // win probability
        uint128 amount,   // ticket face value
        uint256 expire,   // deadline
        bytes memory sig  // client signature
    ) external;
}

Ticket is a signed message from client with parameters: face value, probability, provider public key, expire. Provider holds ticket and can call grab if desired, passing random secret. If hash(secret) < ratio * 2^256—ticket is winning, provider receives amount.

Ticket Flow in Detail

1. Client: generates session keypair (secp256k1)
2. Client → Lottery contract: pushFunds(OXT amount, escrow)
3. Client → Provider: negotiate (select exit node, agree parameters)
4. When sending data:
   - client every ~10 seconds generates ticket
   - ticket = sign({faceValue, winProb, providerKey, nonce, expire})
   - sends ticket to provider via opaque channel
5. Provider: accumulates tickets
6. On winning: grab() → receive OXT
7. Non-winning tickets: discarded (no gas spent)

Economics: client spends OXT evenly over session duration. Provider receives statistically expected payment for bandwidth, periodically collecting winning tickets.

Integration: Use Cases

As Exit Node Operator

If you want to monetize bandwidth (VPS provider, CDN node):

# Launch Orchid provider
docker run -d \
  --name orchid-provider \
  --network host \
  -e ORCHID_SECRET="0x...your-provider-private-key..." \
  -e ORCHID_STAKE="1000"  \  # OXT stake in Lottery contract
  orchidtech/orchid-server:latest

# Register in Orchid directory (on-chain)
# Stake OXT in directory contract for discovery

Clients select providers weighted by stake: more OXT in stake → higher probability of selection. This is a market mechanism against Sybil attacks.

Embedded VPN in dApp

// Orchid Web3 SDK integration
import { OrchidSDK, Account } from '@orchid-protocol/web3-sdk'

const orchid = new OrchidSDK({
  rpcUrl: 'https://mainnet.infura.io/v3/YOUR_KEY',
  // Can use Gnosis Chain for cheaper transactions
  lotteryContract: '0x6dB8381b2B41b74E17F5D4eB82E8d5b04ddA0a82'
})

// Create or load Orchid account
const account = await Account.load(privateKey)
await account.fundAccount(orchid, oxtAmount) // deposit in Lottery

// Create VPN connection via Orchid
const connection = await orchid.connect({
  account,
  hops: 2,           // multi-hop for extra privacy
  currency: 'OXT',
  provider: null     // null = random selection by stake
})

connection.on('stats', ({ bytesSent, bytesReceived, cost }) => {
  console.log(`Used ${bytesReceived} bytes, cost: ${cost} OXT`)
})

Integrate Nanopayment Contract in Your Project

Probabilistic micropayments pattern applies beyond bandwidth. Any service with high-frequency micropayments (AI inference, compute, storage) can use the same model.

// Adaptation of Orchid pattern for compute marketplace
contract ComputeLottery {
    // Every N inference requests—one ticket with 1/N probability
    // Expected payment = faceValue
    // Gas: one transaction per N requests instead of N transactions
    
    function verifyAndClaim(
        bytes32 ticketHash,
        uint256 randomness,   // from VRF or commit-reveal
        uint128 faceValue,
        uint32  probability,  // out of 2^32
        bytes calldata sig
    ) external {
        // Verify client signature
        address client = recoverSigner(ticketHash, sig);
        
        // Probabilistic check
        uint256 roll = uint256(keccak256(abi.encodePacked(randomness, ticketHash)));
        require(roll < uint256(probability) * (type(uint256).max / type(uint32).max), 
                "Not a winner");
        
        // Pay provider
        _transfer(client, msg.sender, faceValue);
    }
}

Multi-hop and Privacy

Orchid supports chains of multiple hops: traffic is encrypted at each level, each hop knows only previous and next node. Two hops are standard configuration, providing privacy close to Tor with better performance.

Each hop pays independently via Orchid nanopayments. Client deposits funds for each hop separately. Nanopayments overhead is minimal—ticket is just signed bytes, transmitted in-band with data.

Technical Limitations

OXT liquidity. OXT is not the most liquid token. For product with wide audience: consider Orchid on Gnosis Chain (xDAI as payment, cheaper gas). Orchid supports multiple chains.

Latency. Each hop adds ~20-50ms. Two hops → +100ms. For video noticeable, for web browsing—acceptable.

Provider discovery. Orchid directory is on-chain, but provider selection is client logic. Weak provider with high stake can get traffic. No built-in reputation system—only stake.

Development Process

Analytics (2-3 days). Determine use case: embed VPN in existing product or build new service on Orchid nanopayment pattern. Different tasks—different scope.

Development (3-6 weeks). SDK integration for VPN use case—2-3 weeks. Custom lottery contract for new nanopayment application—4-6 weeks including testing.

Testing. Must test ticket grinding: ensure provider cannot predict winning tickets beforehand. Randomness source is critical for fairness.