Skip to main content

​
Self-Custodial Architecture

BULK is self-custodial. All assets are held in a Solana program. Deposits and withdrawals natively settle on Solana. The BULK network handles the order book and risk engine, while the on-chain program is the custodian. Each user’s funds are held in a per-user PDA (a program-derived account that is self-custodial and can only be accessed by the user). No operator, validator, or third party can move funds without the user initiating a transaction. Deposits and withdrawals are special transactions on the BULK network:
  • Deposits: A user sends tokens to the Solana program. A plugin forwards the confirmed event to the BULK network. The user’s balance is credited only after Solana has finalized the transaction (approximately 12 seconds).
  • Withdrawals: A user requests a withdrawal through the BULK network. The request passes through consensus, all validators agree on the amount and recipient, and the validator set produces a FROST threshold signature to authorize the on-chain settlement. No single validator can unilaterally release funds.

​
Consensus-Secured Settlement

Deposits and withdrawals are special transactions on the BULK network that must pass through BULKBFT consensus before any state change occurs. Deposit confirmation - When a user deposits to the Solana program, a plugin transfers the state message to the BULK network. A deposit is only confirmed after Solana has finalized the slot. Until finalization, the balance is not available. Withdrawal consensus - When a user requests a withdrawal, the network verifies the account has sufficient available balance (accounting for open positions and margin requirements). The withdrawal is included in a consensus block voted on by the validators. Only after commit do the validators produce valid threshold signatures needed to execute the on-chain instruction. Withdrawal safety - Before any tokens leave an account: available=balance−required margin−unrealized losses\text{available} = \text{balance} - \text{required margin} - \text{unrealized losses} If the withdrawal amount exceeds available balance, the request is rejected.

​
Threshold Signatures (FROST)

Withdrawals from the Solana program require a threshold signature using FROST (Flexible Round-Optimized Schnorr Threshold signatures). The validator set collectively holds a group signing key - no single validator possesses the full private key.
  • The FROST group key is registered in the on-chain program state during initialization
  • To sign a withdrawal, a threshold of validators must participate in the signing ceremony
  • If a validator goes offline, the remaining validators can still produce valid signatures as long as the threshold is met
  • A compromised or malicious validator cannot steal funds - an attacker would need to compromise a threshold number of validators simultaneously

​
On-Chain Program

This program essentially acts as a bridge for deposits and withdrawals. All margining, order matching, liquidation, and other critical lifecycle operations are handled by the BULK network’s deterministic execution layer - they do not depend on this on-chain program.

​
Transaction Authentication

Every transaction submitted to the BULK network is cryptographically signed using Ed25519. Before a transaction enters the execution pipeline, it passes through a multi-layer authentication process: Signature verification - At the network ingress layer, each transaction’s Ed25519 signature is verified against the declared signer. Transactions with invalid signatures are immediately rejected and never reach consensus. Authorization check - Beyond signature validity, the system checks whether the signer is authorized to act on the target account:
  • The account owner is always authorized
  • Registered agent wallets (keychains) are authorized for the owner’s account
  • A parent account’s owner or agents are authorized for its sub-accounts
Unauthorized signers are rejected even if their Ed25519 signature is valid.

​
Validator-to-Validator Communication

All inter-validator communication is secured by WireAuth - authenticated Noise protocol channels that provide encryption and identity binding between every pair of validators. Each validator performs a Noise handshake with every peer at startup, establishing encrypted sessions. Messages are authenticated such that a validator cannot forge messages from another peer.