GOAT Network Decentralized Sequencing
GOAT Network implements a permissionless decentralized sequencer model to enhance security, censorship resistance, and liveness for all L2 transactions. Unlike traditional centralized sequencer models, GOAT shares network ownership with outside sequencer node operators, eliminating single-point-of-failure risk while ensuring 24/7 liveness on the network.
Decentralized sequencers also generate sequencer revenues and sustainable yield for participants supplying BTC or DOGE. Fast L2 confirmation gives apps and agents quick feedback, while Bitcoin finality provides the long-term settlement anchor.
Key Properties
| Property | What it means |
|---|---|
| Trust-minimization | Block production rotates among staked validators through a deterministic selection process, limiting MEV extraction and preventing single-entity transaction ordering. |
| Censorship resistance | Transactions are ordered through consensus with distributed nodes. Users can relay to alternate sequencers if a transaction is declined, instead of relying only on forced-inclusion escape hatches. |
| Liveness guarantees | GOAT Network remains operational even if some nodes fail. With CometBFT-based consensus, the network continues functioning as long as at least 2/3 of validators are online and honest. |
| Bitcoin-backed settlement | Sequencer output is ultimately published and finalized on Bitcoin. |
Architecture Overview
GOAT Network uses a hybrid architecture with CometBFT for transaction ordering and goat-geth for EVM execution. The separation between the layers allows for robust consensus and full EVM compatibility — the consensus layer instructs the execution layer to build blocks and validates the results before finalizing.
- The consensus layer (CometBFT-based client) is responsible for transaction ordering, validator management, and bridging coordination.
- The execution layer (geth-based client) is responsible for transaction execution and maintaining the smart contract state.
Operator Roles
The sequencer consists of two operator types:
- Validators — Participate in CometBFT consensus to order transactions and produce blocks. Validators stake tokens to earn the right to participate and receive block rewards.
- Relayers (Voters) — Operate the bridge by voting on Bitcoin block headers and processing deposit and withdrawal requests. Relayers use BLS threshold signatures to authorize bridge operations.
A separate relayer network handles GOAT's bridge operations. See GOAT BitVM Bridge for the full bridge architecture.
Staking and Validator Registration
Validators join the network by staking tokens through the Locking smart contract on the execution layer. For details on running a validator node, refer to the Validator Guide.
Block Production Flow
Transaction submission
Users submit transactions to any GOAT RPC node. Transactions enter the mempool and propagate across the network.
Proposer selection
CometBFT selects a block proposer based on voting power. The proposer rotates each block, introducing a competitive dynamic that limits MEV extraction.
Block building
The proposer collects pending transactions from the mempool, requests an execution block to be built from goat-geth, and packages the execution payload into a consensus block proposal.
Consensus voting
Other validators verify the proposal by checking that the proposer is valid, validating the execution payload against the execution layer, and voting to accept or reject.
Finalization
Once at least 2/3 of validators vote to accept, the block is confirmed with immediate BFT finality — no reorganization is possible under normal operation. This allows faster bridging to and from Bitcoin and an overall better user experience.
Publish to Bitcoin
The relevant state data is committed to Bitcoin so the chain can inherit Bitcoin-backed finality and dispute resolution.
Resolve disputes if necessary
If someone uses the wrong state or wrong public inputs, challengers and watchtowers can trigger the correct resolution path.
Slashing Conditions
Validator slashing
To ensure validators behave honestly and remain online, they face penalties for the following misbehaviors:
| Condition | Outcome |
|---|---|
| Double signing — proposing conflicting blocks | Stake is slashed; validator is permanently removed from the validator set. |
| Extended downtime — missing too many blocks | Validator is temporarily jailed and removed from the active set. |
Operator slashing
| Condition | Outcome |
|---|---|
| Invalid state use | The offending actor can be challenged and penalized. |
| Invalid reimbursement claim | Operator stake can be slashed. |
| Failure to respond during dispute window | The non-responsive actor loses collateral. |
Sequencing is the fast-feedback layer, not the final-settlement layer. Read GOAT BitVM Bridge for the settlement path and Security Model for the wider trust model. For the full technical implementation, see the GOAT Network GitHub repository.