π ZeroXBridge Sequencer is a Rust-based system that manages cross-chain deposits and withdrawals between Ethereum (L1) and Starknet (L2). It ensures secure, trustless synchronization of user balances using Merkle Trees and Zero-Knowledge Proofs (ZKPs).
The sequencer is responsible for:
- Processing deposit requests on L1 and enabling users to claim pegged tokens on L2.
- Processing withdrawal requests on L2 and enabling users to redeem assets on L1.
- Maintaining a Merkle Tree that tracks deposits and withdrawals.
- Generating STARK proofs for verification.
- Relaying transactions to Ethereum and Starknet.
The sequencer is divided into four core services:
- Exposes endpoints to accept deposit and withdrawal requests.
- Stores requests in a PostgreSQL database.
- Returns a commitment hash for tracking.
- Fetches pending transactions from the database.
- Pushes transactions into the L1 or L2 processing queue:
- L1 Queue β Primarily deposit requests.
- L2 Queue β Primarily withdrawal requests.
- Delays & Retries prevent excessive blockchain queries.
- Performs validation checks before sending to the Proof Generation Service.
- Uses
stwoorstoneprover to generate STARK proofs. - Works with Merkle Roots from L1 and L2.
- Only processes proofs (no blockchain validation).
- Fetches "ready for relay" transactions.
- Sends transactions to Ethereum (L1) or Starknet (L2).
- Waits for on-chain confirmation before marking requests as
complete.
- Periodically fetches the total TVL from the L1 contract using get_total_tvl() (already aggregated via Chainlink).
- Compares it with the L2 oracle contract value via get_total_tvl().
- If the difference exceeds a configurable tolerance, it calls update_tvl() on L2 to sync the state.
- Helps ensure users receive a fair amount of tokens on L2 based on real L1 reserves.
- Reduces update frequency by enforcing range-based thresholding (e.g., >1% deviation).
- User deposits funds on L1.
- API Service stores the deposit request (
pendingstatus). - Queue Service picks up the request, waits, and validates:
- Commitment hash exists on L1.
- Merkle Root has been updated.
- If valid, request is sent to Proof Generation Service.
- Proof Generation Service:
- Generates a STARK proof for deposit inclusion.
- Relayer Service:
- Bundles transaction data.
- Sends the proof to L2.
- L2 verification succeeds, and the user can claim their pegged tokens.
- User requests withdrawal on L2.
- API Service stores the withdrawal request (
pendingstatus). - Queue Service picks up the request, waits, and validates:
- Commitment hash exists on L2.
- Merkle Root has been updated.
- If valid, request is sent to Proof Generation Service.
- Proof Generation Service:
- Generates a STARK proof for withdrawal inclusion.
- Relayer Service:
- Bundles transaction data.
- Sends the proof to L1.
- L1 verification succeeds, and the user can claim their tokens.
zeroXBridge-sequencer/
βββ src/
β βββ api/ # API Service (Handles deposit/withdrawal requests)
β β βββ routes.rs # API endpoints
β β βββ handlers.rs # Request processing logic
β β βββ database.rs # DB connections
β βββ queue/ # Queue Service (Processes pending commitments)
β β βββ l1_queue.rs # Handles L1 deposit requests
β β βββ l2_queue.rs # Handles L2 withdrawal requests
β βββ proof_generator/ # Proof Generation Service (ZKP computation)
β β βββ stark_prover.rs # Generates proofs using `stwo` or `stone`
β βββ relayer/ # Relayer Service (Sends proofs to L1/L2)
β β βββ ethereum_relayer.rs # Sends proofs to Ethereum
β β βββ starknet_relayer.rs # Sends proofs to Starknet
β βββ oracle_service/ # Oracle Service logic
β β βββ tvl_sync.rs # Periodically fetches and updates TVL
β βββ merkle_tree.rs # Merkle tree implementation
β βββ main.rs # Main entry point
βββ tests/ # Unit & integration tests
βββ config.toml # Config files (DB, RPC endpoints, etc.)
βββ scripts/ # Deployment & management scripts
βββ README.md # Documentation
βββ Cargo.toml # Rust dependencies
cargo buildcargo runThe following make targets are available:
- common-start: Builds the Docker image, runs the container, and applies migrations.
make common-start
- docker-build: Builds the Docker image.
make docker-build
- docker-run: Runs the Docker container using environment variables from the
.envfile.make docker-run
- migrate-run: Runs pending SQLx migrations.
make migrate-run
- migrate-info: Displays current SQLx migration status.
make migrate-info
- migrate-revert: Reverts the last applied migration.
make migrate-revert
- clean: Stops and removes the Docker container.
make clean
Before applying for any of our issues, we'd appreciate if you could star our repo! This helps boost our project visibility and makes it easier for you to find us in your GitHub stars for future contributions. Thanks for your support! β
- Browse open issues.
- Ask to be assigned to an issue.
- Follow the project structure.
- Write unit tests for your feature.
- Run
cargo testto verify your changes.
- Link your PR to the issue.
- Provide clear documentation.
- Include logs/test results in your PR description.
- Maintain clean, readable code.
- Respond to feedback and iterate as needed.
- High-quality contributions are eligible for OnlyDust Retroactive Grant Funding.
- Minor fixes (typos, small tweaks) will not be rewarded.
- Code quality matters more than speedβensure proper tests and documentation.
π Yo, Letβs Go!
π₯ ZeroXBridge Sequencer is ready for contributors!
Drop into the issues section and letβs build! π―π₯