# TRITO — Merit-Based Sequencer Selection for Rollups

### A burn-entropy, merit-weighted protocol for decentralizing who orders transactions

**Version 4.0 · July 2026**
Website: [tritotoken.eu](https://tritotoken.eu) · Code: [github.com/JordanKP87/trito-coin](https://github.com/JordanKP87/trito-coin)

> **Testnet notice.** TRITO is live on Arbitrum Sepolia. Tokens have no monetary value today. Nothing in this document is an offer of securities or investment advice.

---

## Executive summary

Rollups scaled Ethereum's execution. They did not decentralize its **ordering**. Nearly every major rollup today runs a single sequencer — one operator that decides which transactions go into a block and in what order. It is the most centralized component in an otherwise trust-minimized stack, and it is the industry's most consequential unsolved problem.

**TRITO is a protocol that decides *who* gets to seal each block, using merit rather than capital.** It selects three equal sealers per slot from a pool of participants ranked by demonstrated, multi-dimensional commitment — then draws among them with Chainlink VRF, seeded by entropy that is expensive to manufacture because it is derived from real economic burns. No node seals alone: a slot is sealed only when two of the three independently submit the same result, and only those who are right are paid.

Three components make this work:

- **PoHH (Proof of Hidden History)** — consensus entropy sourced from actual token burns, so influencing the draw costs real value rather than compute.
- **PoCS (Proof of Commitment & Streak)** — separates *eligibility* (having stake) from *influence* (how long and how consistently you've committed), which removes wealth-proportional control.
- **CeR (Community Engagement Rank)** — merit tickets earned across independent activity dimensions, making selection weight reflect participation rather than balance.

The system is **implemented, tested, and running**: eleven Solidity contracts, 260 passing tests, live on Arbitrum Sepolia, with a working mobile app, web app, desktop node client, and a 24/7 sealing service. A charity mechanism is embedded at the protocol layer — a fixed share of every transfer routes to a charity treasury, permanently and by contract.

**Status:** testnet-complete, pre-audit, pre-TGE. Raise terms and valuation: *TBD*.

---

## 1. The problem: rollups centralized the sequencer

A rollup's sequencer holds three powers: it decides transaction **inclusion**, transaction **order**, and it is a single point of **liveness failure**. Concentrating those in one operator reintroduces exactly the trust assumptions rollups were built to remove. The consequences are practical, not theoretical: censorship capability, MEV extraction, and outages that halt an entire chain.

The ecosystem broadly agrees decentralized sequencing is necessary. What remains unsettled is the **selection rule** — the mechanism deciding which operator sequences which block. Most proposals default to one of two answers, and both have known failure modes:

**Stake-weighted selection** makes influence proportional to capital. The largest holder sequences the most blocks. This is plutocracy with extra steps, and it concentrates over time.

**Round-robin or committee rotation** is fairer but static. It has no notion of merit, contribution, or good behavior — an idle operator and a deeply committed one are treated identically, and Sybil operators are limited only by an entry cost.

**TRITO's thesis: sequencer selection should be a merit function, not a balance lookup — and its randomness should be economically expensive to bias.**

## 2. What TRITO actually is

TRITO is not a new L1, and it does not ask anyone to bootstrap a new validator set. It is a **selection layer**: a set of contracts that answer "who seals this slot?" and prove that answer was reached fairly.

The protocol runs a repeating slot cycle:

1. **Slot opens.** The sequencer contract requests randomness from Chainlink VRF and advances the slot.
2. **Entropy is composed.** The VRF word is combined with **burn-derived entropy** (PoHH) — a real, on-chain burn event drawn from the previous slot's pool, augmented by that slot's committee leaves when trading was sparse (§2.1).
3. **The eligible set is weighted.** Each registered node's selection weight comes from its **CeR ticket count**, itself a function of staking commitment, streak consistency, and activity (PoCS + CeR).
4. **Three equal sealers are drawn**, ticket-weighted, from that set. There is no leader: the three carry identical duty, identical authority, and identical reward.
5. **They attest.** Each independently derives the same result from chain state and submits it within a fixed window. **The slot seals only when two of the three submit the *same* value** — and only those who match are paid. Rewards mint to the node **owner**, never to the operational key that signs.

Three properties fall out of this design and are, we believe, the novel contributions.

### 2.1 Entropy that costs money to manipulate

Randomness in consensus is usually cheap to grind: an attacker with compute can search for favorable outcomes. In PoHH, part of the seed is drawn from **actual burn events** recorded during trading. To bias the draw, an adversary must generate real burns — destroying real value — and must do so without knowing which burn will be chosen, because selection among the burn pool is itself VRF-determined.

This produces a security property that **scales with economic activity**: the more the network is used, the deeper the burn pool and the more expensive manipulation becomes. Security is funded by usage rather than by emission.

**The low-activity problem, and how it is solved.** Entropy sourced from trading has an obvious weakness: a quiet slot produces few burns, and a thin pool is a weak pool. Early designs handled this by falling back to the last active slot — correct, but it means entropy can go stale during quiet periods.

TRITO resolves this by making **consensus itself a second entropy source**. At the moment a slot is fulfilled, the protocol records three additional entropy leaves derived from the VRF-selected committee — one per selected participant — each computed as `keccak256(vrfRandomWord, fulfillmentTimestamp, selectedOwner)`. Selection then proceeds in tiers:

- **Busy slot** (burns above the minimum): the draw uses **burn leaves** plus any merit-credential leaves.
- **Quiet slot** (burns at or below the minimum): the draw uses the **union of burn leaves, that slot's three committee leaves, and any credential leaves**.

Credential leaves come from a separate class of participation-only tokens (§6) and are counted at **both** tiers, not merely as a quiet-slot fallback. The reason is that they are the one part of the entropy supply an attacker cannot buy: trade burns can be manufactured by anyone with capital, whereas credentials are earned only through sustained participation. Excluding them from busy slots would discard precisely the entropy that is hardest to forge.

Because every fulfilled slot deposits exactly three committee leaves, the pool is **never smaller than the required minimum**. The blockhash fallback that would otherwise be needed is reachable only at genesis. The practical effect: entropy remains VRF-grade and fresh even with zero trading, so liveness no longer depends on market activity.

Critically, these leaves are **not grindable**. Every input is fixed at fulfillment time — the VRF word, the block timestamp of fulfillment, and the owner address selected by that VRF word. A participant cannot influence the future entropy pool by choosing whether or not to seal, by timing its transaction, or by declining selection. The committee contributes entropy by virtue of *having been chosen*, not by anything it subsequently does.

This is the same design philosophy as the burn mechanism, applied recursively: the cost of influencing consensus randomness is either real economic value (burns) or control of the VRF itself (infeasible), never mere participation.

### 2.2 No single node can seal a slot

Selection answers *who may act*. It does not answer *whether what they did was right* — and a protocol that pays for the first answer alone is paying for presence, not for work.

TRITO therefore separates the two. Being drawn mints nothing. Each of the three sealers independently derives the slot's result from chain state and submits it during a fixed window (default 300 seconds). When the window closes, agreement is evaluated **once**:

- **Two or three matching submissions** → that value becomes the slot's canonical result, the slot seals, and every member that matched is paid in full.
- **One submission, or three that disagree** → no canonical result exists, the slot does not seal, and **nothing is minted to anyone**.

A member that submits a value the committee rejects earns nothing, and its dissent is recorded on-chain as evidence rather than discarded.

**Why a window rather than a race.** Sealing on whichever pair matched first would pay for speed, and would make a participant's earnings depend on when its peers happened to be online. Evaluating once at the close removes that entirely: submission order carries no reward consequence. Being fast is worth nothing; being right is worth everything.

**Why two of three rather than unanimity.** Requiring all three multiplies availability: at 90% per-node uptime, barely 73% of slots would ever seal, and a crashed node is indistinguishable from a hostile one. A two-of-three threshold tolerates a single failure while leaving a lone dishonest node unpaid.

We state the limit plainly: with three members, two colluding members can outvote one honest member. The defence is not committee size — it is that all three are drawn by VRF from the ticket-weighted pool, so capturing two seats in the same slot requires controlling a substantial share of CeR-weighted nodes, and cannot be arranged in advance.

What this buys, precisely: **a slot's result is corroborated by at least two independently-operated nodes that each staked their reward on it.** A consumer that wants provenance can check the selection; a consumer that wants correctness can additionally require agreement.

### 2.3 Issuance backed by destruction, not by self-report

The reward for a slot was previously derived from a transaction count supplied by whoever opened it. That is a number the protocol had to trust, and trusted numbers are the wrong foundation for issuance.

Rewards are now computed from **TRITO actually burned in the preceding slot**, read on-chain:

```
reward = (burnVolume − opexBuffer) ÷ deflationRatio     [capped]
```

Three consequences follow structurally rather than by policy. Dividing by a ratio of at least 1.0 makes issuance **strictly smaller than the destruction that funded it**, at every volume — the protocol cannot be inflationary by construction, and no administrator can make it so. Subtracting an operating buffer first means the protocol pays its own running costs out of deflation rather than out of holders. And no off-chain actor can inflate rewards by reporting a number, because no reported number enters the calculation.

**A slot must also earn the right to open.** The preceding slot must have cleared two independent bars — a minimum volume burned *and* a minimum count of distinct burn events. Neither implies the other: a single large transfer clears any volume bar while producing exactly one event. Requiring both means every sealed slot is provably preceded by genuine, multi-party activity, and a quiet market produces no blocks rather than empty ones.

### 2.2 Influence decoupled from wealth

PoCS makes a deliberate separation:

- **Eligibility** = do you have stake at all (a Sybil cost, and skin in the game).
- **Influence** = how *long* you have committed and how *consistently* — expressed through a 21-tier commitment ladder and streak tracking.

A participant who commits modest capital for a long, unbroken period can outrank one who deposits a large sum briefly. Combined with CeR — which awards tickets across **independent** activity pillars, each individually capped — the result is that buying influence is inefficient by construction. Capital alone cannot purchase the top of the ranking; time and participation are required, and neither can be bought instantly.

Early exit remains possible: an early unstake returns full principal with a reduced (50%) APR for days actually held. Commitment is incentivized, not imprisoned.

## 3. Why this is a protocol, not just a token

The distinction matters for evaluating TRITO. The selection logic is implemented in contracts (`TRITOSequencer`, `CEROracle`, `TRITOStaking`) that consume a slot request and emit a verifiable outcome: **who was selected, and the proof they sealed**.

That outcome is now exposed through a standard, chain-agnostic interface — **`ISequencerSelector`** — so an external rollup or shared-sequencing layer can consume it directly:

```solidity
interface ISequencerSelector {
    function selectionFor(uint256 slotId) external view returns (Attestation memory);
    function isAuthorizedSequencer(uint256 slotId, address claimed) external view returns (bool);
    function verifySeal(uint256 slotId) external view returns (bool);
}
```

The design principle is that a consumer **never has to trust TRITO**. Each attestation carries the Chainlink VRF request that produced the draw (checkable against the coordinator, unforgeable), the PoHH seal, and its component parts — and `verifySeal()` re-derives `keccak256(pohHash, bhhEntropy, slotId)` so the consumer confirms the published seal actually binds the published entropy. If anything fails to reconcile, the selection is rejected. TRITO is a *source*, not an authority.

**Selection is reproducible, not merely verifiable.** Verifying entropy proves the draw wasn't tampered with; it does not explain *why* a particular node won. Because selection is ticket-weighted from CeR state that changes continuously, that gap would normally force an observer to trust the operator's account of the weighting.

TRITO closes it by committing, atomically with each draw, to the exact weight vector used:

```
weightsRoot = keccak256(abi.encode(nodes, effectiveTickets, poolSize))
```

Cooldown is folded into `effectiveTickets` (a cooled node carries zero), which makes the commitment self-contained — no historical state is needed to interpret it. An observer holding the published leaf set can therefore do two things: confirm it matches the committed root (`verifyWeights`), and **re-run the draw itself** to derive the leader (`recomputeLeader`). `auditSelection()` performs both and reports whether the recomputed leader equals the one actually recorded on-chain.

The practical consequence is that every claim in a TRITO selection is independently checkable by a third party: the randomness (Chainlink), the entropy (recomputable from burns and committee leaves), the weighting (committed root), and the outcome (recomputed draw). None of them require trusting an operator, a multisig, or an off-chain service.

The implementation is deliberately **additive**: `TritoSequencerSelector` is a read-only adapter over the live sequencer. It holds no funds, cannot mint, cannot write to the sequencer, and cannot alter a selection — so exposing the external interface carries no risk to the running consensus system, and the interface can evolve without touching consensus code.

A reference consumer (`ExampleRollupGate`) demonstrates the full integration in roughly sixty lines: it accepts a block only if the submitter was selected for that slot **and** the seal verifies. The accompanying test suite asserts that selected sequencers are accepted, non-selected addresses are rejected, unfulfilled slots authorize nobody, and attestations are tamper-evident.

**Current maturity, stated plainly.** The interface, adapter, reference consumer, weight commitments, and tests exist and pass. What does *not* yet exist is a production integration with a third-party rollup, and one engineering increment remains: **cross-chain relay** of attestations via CCIP, for consumers not on Arbitrum. Same-chain consumers are supported today, and the leaf set backing each weight commitment is published off-chain (keeping per-slot gas constant regardless of operator count) — the same pattern used by merkle-based distribution systems.

## 4. Architecture

### 4.1 Where it runs, and why

TRITO's full contract suite is deployed **natively on Arbitrum**, with all economic activity — staking, sealing, rewards, burns — executing at L2 cost and speed. A thin, bridge-controlled mirror of the token is planned for Ethereum L1 to serve as canonical presence for listings and custody.

The choice of Arbitrum is deliberate and reversible in principle, but reasoned:

- **Chainlink VRF and CCIP are both live there**, and the protocol depends on VRF for selection.
- **Deepest L2 DeFi liquidity**, which matters for a token whose burn rate is volume-adjusted.
- **~0.25s block times and sub-cent fees**, suited to a seal-heavy, many-small-transaction economy.
- **Arbitrum Orbit provides a credible path to a sovereign chain** — the option to run PoHH + CeR as a chain's own sequencer-selection layer, without committing to that cost now.

### 4.2 The token *is* the monetary policy

TRITO is not a passive ERC-20 wrapped in external logic. The token contract itself holds the free-supply reserve, the burn engine, the four-state economy machine, and the PoHH burn-event recorder. Other modules call into it under strict authorization. This is why the token and its mechanics are co-located on one chain: they are inseparable.

**Four-state economy.** The contract transitions automatically on circulating supply:

| State | Trigger | Burn behavior | Staking APR |
|---|---|---|---|
| Normal | < 2.5B | Volume-adjusted base rate | Full (5%–130%) |
| Warning | 2.0B–2.5B | 1×/2×/3× base (tiered) | Reduced 10–30% |
| SOS | ≥ 2.5B | 10× base | 5% flat |
| Hard Cap | ≥ 2.8B | 15× base | Zero |

Recovery is symmetric: once in an emergency state the system keeps burning hard until circulating supply returns to the 2.0B baseline, then resumes Normal. A deep-emergency tier ("Last Man Standing") switches the burn from the reserve to a share of trade volume when the reserve is nearly exhausted — so deflation targets the pool that inflated, and the system can heal without an infinite reserve.

**Volume-adjusted burn.** Burn rate scales inversely with daily volume across seven tiers (3% at low volume down to 0.01% above $2B/day) — aggressive deflation when the network is small, negligible friction at scale.

### 4.3 Operator/owner key separation

A node's **owner** (the wallet holding stake, receiving all rewards) is distinct from its **signer** (an operational hot key that can *only* submit attestations). The signer never custodies stake or rewards. This lets a node run 24/7 on a server or desktop while the valuable key stays in the user's control, and lets the owner rotate or revoke the signer instantly on-chain.

## 5. What is built and working

This is the part we ask investors to weigh most heavily: TRITO is not a paper design.

**Smart contracts (9)** — Token, Staking, CEROracle, Sequencer, Rebalancer, ReleaseCalendar, VestingVault, RegistrationGift, AirdropDistributor. **206 tests passing** (Hardhat, Mocha, Ethers v6). Deployed and operating on Arbitrum Sepolia.

**Externally-consumable selection layer** — `ISequencerSelector` interface, a read-only adapter over the live sequencer, a reference rollup integration, and per-slot weight commitments that let any third party **reproduce** a selection rather than trust it. Covered by dedicated test suites proving that only TRITO-selected sequencers are authorized, that tampering with a published weight set is detected, and that re-running a draw yields the leader actually recorded on-chain.

**Mobile application** (React Native / Expo, Android) — account creation with a non-custodial **embedded wallet** (no seed phrase, no browser extension), staking, node registration, signer authorization, wallet send/receive, live dashboard, and 15-language localization.

**Web application** (Next.js) — full parity for account, staking, node management, and governance views, using the same embedded wallet.

**Desktop node client** (Tauri) — a dedicated sealing console that ties to the user's account, generates a local signer, and seals continuously. No browser wallet required.

**24/7 sealing service** — a managed multi-node sealer that operates authorized signers on behalf of users who prefer not to run hardware, plus a keeper for slot progression.

**Onboarding without friction** — new accounts receive an automatic gas top-up, so a first-time user can register, claim, stake, and run a node without ever visiting a faucet or buying gas manually. Combined with embedded wallets, this removes the two largest drop-off points in crypto onboarding.

## 6. Tokenomics

```
Initial supply        2,000,000,000 TRITO
SOS threshold         2,500,000,000 TRITO
Hard cap              2,800,000,000 TRITO
Recovery baseline     2,000,000,000 TRITO

Transfer tax          0.6% total (0.3% charity + 0.3% development)
                      Hard-capped by immutable ceilings: charity ≤ 1.1%,
                      dev ≤ 0.9%, combined ≤ 2.0% — the cap cannot be raised.

Burn                  Volume-adjusted, 7 tiers (3.0% → 0.01%),
                      multiplied 10× in SOS and 15× at hard cap.

Staking               21 commitment tiers, 5%–130% APR,
                      dynamically reduced by economy state.
Early unstake         Full principal returned, 50% APR for days held.

Airdrop pool          150,000,000 TRITO (7.5%)
                        Activity 100M · Referral 40M · Bonus 10M
Registration gift     500 TRITO (first 10,000 members)
```

**The charity mechanism is structural, not promotional.** A share of every taxed transfer routes to a charity treasury by contract. The rate is governable within immutable caps, and the destination is a multi-signature treasury. It cannot be switched off by a future administrator, and the maximum extraction is bounded forever at 2%.

**Distribution, vesting, and public sale terms:** *TBD* — to be finalized with lead investors prior to TGE.

## 7. Governance and security posture

Ownership of the protocol's administrative functions is being migrated to **multi-signature control** (Gnosis Safe) across separate charity, development, treasury, and admin roles. Critically, the authority that designates the sequencer contract — and therefore who may mint — will sit behind that multisig before mainnet.

We are candid about what remains:

- **A full third-party audit has not yet been completed.** It is a gating requirement before mainnet deployment, and it must cover the cross-chain bridge, which is the newest and highest-risk surface.
- **The L1 mirror and bridge are designed but not yet deployed.**
- **Testnet contracts are unaudited and hold no value.**
- **The deflation ratio is not yet modelled.** Issuance divides burn volume by a governable ratio, currently 1.2. That it is bounded at or above 1.0 guarantees the protocol can never be inflationary; it does not establish that 1.2 is the *right* value. Modelling against real emission curves is outstanding.
- **Keeper cadence influences aggregate issuance.** Because each slot's reward is capped regardless of how much burned, opening slots more frequently mints more in total for identical market activity. Always deflationary, but a monetary lever currently sitting in an operational component.
- **Committee agreement is corroboration, not proof of independent computation.** Submissions are public before the window closes, so a dishonest member could copy rather than derive. The honest cost of deriving is a single chain read, so the incentive to copy is negligible — but the guarantee we claim is that two independently-operated nodes each committed to the same result, not that each computed it in isolation. A commit-reveal scheme would close this if measurement ever shows it matters.

*Resolved since the previous edition: reward emission was previously driven by a transaction count supplied by the slot opener, which would have over-minted at mainnet scale. Issuance is now derived from on-chain burn volume and cannot be influenced by any reported figure (§2.3).*

We would rather state these plainly than have a diligence process discover them.

## 8. Roadmap

**Complete** — Tri-Pillar protocol implementation; eleven contracts with 260 tests; Arbitrum deployment; mobile, web, and desktop clients; embedded wallets; 24/7 sealing infrastructure; frictionless onboarding.

**Next** — Third-party security audit · multi-signature governance handover · CCIP bridge and Ethereum L1 mirror · liquidity provisioning and fiat on-ramp · Token Generation Event.

**Then** — CCIP relay so off-Arbitrum chains can consume attestations · pursue a first production integration and benchmarking against existing shared-sequencing efforts · evaluate graduation to a dedicated Arbitrum Orbit chain where PoHH + CeR secure sequencing directly.

## 9. Why this is investable

**A real problem with an unsettled answer.** Decentralized sequencing is a named, funded category. TRITO offers a specific, differentiated selection rule rather than a general-purpose chain.

**Working software, not a design document.** Eleven audit-pending contracts, 260 tests, three clients, and live infrastructure — before raising.

**Mechanism design that resists the failure mode of its category.** Merit-weighting plus burn-sourced entropy directly addresses the plutocracy and grinding problems that stake-weighted selection inherits.

**Onboarding that a non-crypto user can complete.** Embedded wallets and automatic gas remove the failure points that gate mainstream adoption — relevant to any protocol whose security depends on a broad operator base.

**A durable, structural charity commitment** that differentiates the narrative without depending on discretionary generosity.

**The honest counterweight:** TRITO is pre-audit, pre-revenue, pre-TGE, and operating in a competitive category alongside well-funded shared-sequencing teams. Its selection mechanism is novel but not yet integrated with an external rollup, and that integration is the key proof point ahead.

---

## Appendix A — Deployed contracts (Arbitrum Sepolia)

| Contract | Address |
|---|---|
| TRITOToken | `0x910B79D12B549aEE00c9477fd92Eb03b2dE5651E` |
| TRITOStaking | `0xe0532e83b22ecC223E418698d58F0d38d6C6102c` |
| CEROracle | `0x65472C54F4Bca78070E023F1FEFCeC8E2291F2a8` |
| TRITORebalancer | `0x5eA1098329509384846065154c0573FAf4994336` |
| TRITOSequencer | `0x155a8ba6fcf81EeBE5AD69b71410375BEf4C8AeB` |
| TritoSequencerSelector | `0x332a51C592F548bAc9cC8dc0B42c6a2207CcB544` |
| TRITOReleaseCalendar | `0x780Eb01151cf92a0d243C686ca334c183505F911` |
| RegistrationGift | `0x6fA6fc327dc340bAbA523151668e347BdcbFF854` |
| TRITOVestingVault | `0x8d392a65b79015EA683F0445bdDC3B7804403d93` |
| TRITOAirdropDistributor | `0x405f1ac7c3E8E29331382eB0AA21aDE76AE3BC53` |

Chain ID 421614 · Explorer: [sepolia.arbiscan.io](https://sepolia.arbiscan.io)

## Appendix B — Protocol specifications

The formal treatment of PoHH, PoCS, and CeR — including entropy construction, the 21-tier ladder, ticket accrual, VRF-weighted selection, game-theoretic analysis, and gas accounting — is maintained as a separate technical paper alongside the source code.

---

*TRITO is a testnet project. Tokens have no monetary value. This document is informational and is not an offer to sell securities, financial advice, or a guarantee of future performance. Figures marked TBD are undetermined and subject to change.*