Stater
Whitepaper

Summary

Stater ($STTR) is a fixed-supply token on Base that lets a user transact on any blockchain while holding only one asset. Instead of acquiring the native gas token of every network they touch, a user holds STTR and the infrastructure settles gas on their behalf.

The token has three roles: it pays for gas across chains, it is the unit of account inside the Stater social-finance application, and it carries governance rights in the Stater DAO at one vote per token.

STTR is deliberately plain as an asset. It has no transfer fee, no freeze or blacklist, no pause switch, and no owner minting. Every one of those mechanisms would break the jobs it has to do — a token used to settle gas and move across bridges has to transfer the exact amount it says it transfers. The contract is built on audited OpenZeppelin components and implements four standards: ERC-20, ERC-2612 for gasless approvals, ERC-5805 for checkpointed voting, and ERC-7802 for native cross-chain movement.

The problem

Every blockchain charges fees in its own native asset. To do anything on Ethereum you need ETH; on Solana, SOL; on Polygon, POL. This is invisible to people already in crypto and close to fatal for everyone else.

The consequences compound:

• A user cannot spend what they hold. Someone holding a stablecoin on a chain where they have no native token is stuck. They own value they cannot move, because moving it costs a different asset they do not have.
• Onboarding to a new chain means starting over. Acquire the native token first, from an exchange or a bridge, before the first transaction. Every additional chain repeats the friction.
• Small balances become unusable. Gas is a fixed cost. A wallet holding a few dollars on three chains may not be able to afford to consolidate them.
• Applications inherit the problem. A multi-chain application cannot onboard a user who has no gas anywhere, so it either subsidises them or loses them.

Existing answers are partial. Bridges move assets but still require gas on both sides. Exchanges solve it only for people who already have an account. Gas sponsorship works but usually ties the user to one application, one chain, and one sponsor's balance sheet.

The missing piece is an asset that is accepted as payment for gas everywhere, that the user holds once and spends anywhere.

How it works

Three mechanisms combine. None of them is exotic; the design choice is refusing to add anything that would break them.

Approving without gas

STTR implements ERC-2612 permit(). A holder authorises a spender by signing a message, not by sending a transaction. Signing costs nothing and requires no native token.

This is the piece that makes the rest possible. A user with STTR and no ETH can still authorise a relayer, because the authorisation never touches the chain until someone else submits it.

This is already running. On Base Sepolia, a wallet holding no ETH can sell STTR by signing an order and a permit; a relayer submits both, pays the gas, and is paid back in STTR out of the sale. The details are under The testnet app, below.

Settling gas through a paymaster

Under ERC-4337 account abstraction, a paymaster pays a transaction's gas in the native asset and takes payment from the user in an ERC-20. The user signs; the paymaster settles.

Paymasters require the amount they pull to equal the amount they receive. A token that skims a fee on transfer causes validation and execution to disagree, and the operation reverts. This is the specific reason STTR has no transfer fee. It is not a marketing decision, it is a functional requirement: a taxed token cannot be used to pay for gas.

Moving between chains without wrapping

STTR implements ERC-7802. Moving between chains burns the tokens on the source chain and mints the same amount on the destination.

The practical effect is that global supply never changes — only its distribution across chains does. There is no wrapped derivative, no separate liquidity pool per chain, and no custodial pot of locked collateral to be drained. Both functions can only be called by bridge contracts the DAO has explicitly authorised.

Token overview

Supply is minted once at deployment and the contract contains no function that can create more. The only way supply moves is downward, through holders burning their own tokens, or sideways between chains through the bridge burn-and-mint mechanism, which conserves the global total.

Base was chosen for three reasons: it is an OP Stack chain inside the Superchain, which gives STTR native cross-chain movement through the canonical bridge rather than a third-party wrapper; it has deep existing liquidity and full Uniswap deployment; and its fees are low enough that gas settlement is economic at small transaction sizes.

Token distribution

The full 10,000,000,000 STTR supply is allocated as follows.

Vesting

The team allocation is split across three founding partners at 70/15/15 — 980,000,000, 210,000,000 and 210,000,000 STTR — and each tranche is locked and released at 5% per month, taking 20 months to unlock in full. The early investor receives 5% at the start and the remaining 95% at the same 5%-per-month rate, completing in 19 months.

Combined, 15% of supply follows this schedule. The only part liquid at launch is the investor’s opening tranche — 5,000,000 STTR, 0.05% of supply. Roughly 60% of the scheduled total has released by month twelve, with the remainder following through month twenty.

The schedule is stated here as the project's commitment. It becomes verifiable once the vesting contracts are deployed and their addresses published — until then a reader should treat it as intent rather than an on-chain guarantee. The date the schedule starts from has not been fixed.

The community airdrop

Twenty percent of supply — 2,000,000,000 STTR — is reserved for the people who use the network rather than fund it. It is the single largest allocation in the table, larger than the team and early investor combined by a wide margin, and that is deliberate: a settlement asset is worth what its users make it worth.

Who it is for

The target is power users of EVM chains — people whose on-chain history shows sustained, genuine activity rather than a wallet created for a snapshot. Activity on Base is weighted most heavily, since that is where Stater is deployed, but the allocation deliberately reaches across EVM networks. Somebody whose behaviour already demonstrates the problem Stater solves — moving between chains, holding balances in several places, paying gas in several assets — is exactly the person the protocol is built for.

What counts

Eligibility is scored across several independent signals, not decided by a single snapshot of a single balance:

• On-chain history across EVM chains, weighted toward Base — depth and consistency of real activity, not one-off volume.
• Testing our products. Using the testnet deployments, reporting defects, and stressing the gas-abstraction flow before it is load-bearing.
• Social participation. Contribution to the community rather than follower counts — answering questions, translating, writing, moderating.
• Further criteria published before the snapshot is taken. The list above is not exhaustive and the weightings are not yet fixed.

It has to be earned

This is not a claim-by-existing distribution. Multi-signal scoring exists to make farming expensive: a wallet optimised for one metric scores poorly across the rest, and sybil clusters are removed rather than diluted. Participants should expect to work for an allocation.

Not yet fixed. Weightings, the snapshot date, the claim window and the sybil methodology are undecided, and none of this is a commitment to any individual amount or to any value. The criteria will be published in full before the snapshot is taken, so nobody is scored against rules they could not read in advance.

Reading this honestly

Forty percent of supply — community airdrop plus grants — is directed outward, to users and to developers who are not the core team. Combined team and early-investor allocation is 15%, which is modest by the standards of the category.

That said, an allocation table is a statement of intent, not a guarantee. What converts it into a commitment is on-chain enforcement: vesting contracts for the team and investor tranches, published addresses for each bucket, and a liquidity lock with a stated duration.

Not yet defined

The following are unresolved at the time of writing, and a reader should treat them as open:

• Vesting start date. The 5% monthly release is set, but the date it begins from has not been fixed.
• Mainnet addresses. The vesting contract, the liquidity lock and the six multisigs exist and have been exercised on Base Sepolia, but nothing is deployed to mainnet. Until those addresses are published, the custody model above is a design rather than a verifiable fact.
• Source verification. The current contracts have not been verified on a public explorer.
• Airdrop weightings and timing. The criteria are described above, but the scoring weights, snapshot date and claim window are not yet fixed.

These are the details that determine whether the distribution above is meaningful. They should be settled and published before any public sale or listing.

Utility

STTR has three distinct roles. Each is a reason to hold it that does not depend on the others.

Universal gas

A user holding STTR can transact on any supported chain without holding that chain's native asset. They sign; a paymaster settles the gas and takes STTR in return. From the user's point of view there is one balance and it works everywhere.

This is the primary demand driver. Gas is consumed continuously by anyone using the network, which ties token demand to actual usage rather than to speculation.

Currency of the Stater application

STTR is the unit of account inside the Stater social-finance application — the asset balances are denominated in and payments are settled in.

The absence of a transfer fee matters here more than anywhere. A social-finance product depends on small, frequent transfers. A three percent cut on every payment would make the product unusable, which is a large part of why the fee was removed during design rather than after launch.

Governance

One token, one vote in the Stater DAO. Holders vote on protocol parameters, treasury allocation, grant funding, and — critically — which bridge contracts are authorised to move supply between chains.

That last power is the most consequential thing the DAO controls, and it is covered in detail in the Governance and Security sections below.

Technical architecture

The contract is a single Solidity file built on OpenZeppelin 5.6.1. Using audited components rather than hand-written equivalents is deliberate: for a project positioned in security infrastructure, "we wrote our own ERC-20" is a liability rather than a credential.

Deployment model

On the home chain, Base, the full supply is minted once. On any other chain, the contract deploys with zero supply — the only tokens that can ever exist there are ones a bridge minted against tokens burned elsewhere. This makes it structurally impossible for a remote deployment to create supply out of nothing.

Cross-chain authorisation

crosschainMint and crosschainBurn are restricted to holders of BRIDGE_ROLE. The role is generic rather than hardcoded to one bridge, so the canonical Superchain bridge, and later a LayerZero or Chainlink CCIP adapter for chains outside the Superchain, can each be authorised without modifying the token.

Two details are worth stating precisely:

• A bridge cannot burn from an arbitrary wallet. crosschainBurn spends an allowance unless the bridge already holds the tokens. A compromised bridge cannot drain holders who never approved it.
• BRIDGE_ROLE can be revoked but not renounced. A bridge abandoning its own role mid-transfer would strand supply in flight, so removal is a deliberate act by the admin rather than something a bridge can do to itself.

Compilation

solc 0.8.28, optimiser enabled at 200 runs, EVM target cancun. Runtime bytecode: Stater 10,254 bytes, StaterVesting 5,765 bytes, StaterLiquidityLock 4,875 bytes, StaterPaymaster 5,531 bytes, StaterIntentEscrow 7,920 bytes, StaterSwapRouter 3,513 bytes — all well inside the 24,576-byte contract limit. The testnet-only contracts behind the public app — StaterPair (8,013 bytes), StaterGaslessRouter (6,835 bytes), StaterOutbox (6,924 bytes) and StaterTestnetSale (4,493 bytes) — are built with the same settings.

Security model

The distinction that matters is between what a project promises and what its code prevents. The following are the second kind — each is verifiable by reading the published source, and none depends on the team's continued good behaviour.

Custody

Every allocation sits in one of three places, and each is a separate address anyone can read on a block explorer.

Separate multisigs rather than one pooled treasury, so each portion's balance and spending history stand on their own. A reader can watch the marketing budget without inferring it from a shared balance.

The admin multisig holds DEFAULT_ADMIN_ROLE and no tokens at all. Compromising it grants no access to any balance.

Liquidity lock

Liquidity provider tokens are deposited into StaterLiquidityLock for 365 days. The contract has no owner, no admin, no pause and no emergency path: nothing in it can release a lock before its date, and no number of signatures changes that. The unlock date can be pushed further out and can never be pulled in, so a published date is a floor rather than an intention. Both LP shapes on Base are supported — ERC-20 pair tokens and ERC-721 concentrated-liquidity positions.

The lock covers the pool, not the whole liquidity allocation. At launch a portion of the 15% is paired on Uniswap and its LP tokens are locked. The rest stays in the liquidity multisig as the reserve for listings on centralised exchanges. That reserve is not locked: two of the three signers can move it, and its balance is public at the multisig's address. The amounts paired and held are published at launch.

Vesting needs no signature

The team and investor schedules are deliberately outside multisig control. release() is permissionless and pays only the beneficiary, so tokens reach the assigned wallets on schedule whether or not any signer is available, willing, or still involved. The multisig cannot speed it up, delay it, or redirect it; after sealing it cannot even recover the vested token.

Who holds the admin role

DEFAULT_ADMIN_ROLE is held by a multisig wallet. Every privileged call — granting or revoking BRIDGE_ROLE, and handing the role onward — requires the multisig's signing threshold, so no single key can act alone. The role can be transferred to a DAO governor later without touching the token contract.

The admin surface is deliberately small: it grants and revokes roles and nothing else. It cannot mint, move, freeze or tax a balance, so a compromised admin cannot take anyone's tokens. The worst it can do is grant BRIDGE_ROLE to an address that should not have it — which is why that role is revocable.

One consequence worth stating: a multisig is a contract and cannot produce an ECDSA signature, so ERC-2612 permit does not work for a contract-held balance. The token implements no ERC-1271 fallback. A multisig treasury approves spenders with approve() instead. This affects contract holders only; ordinary wallets use permit normally.

The trust boundary

There is one, and it should be stated plainly rather than buried: any contract granted BRIDGE_ROLE can mint STTR. That is inherent to burn-and-mint cross-chain movement — a bridge must be able to recreate on one chain what it destroyed on another.

This makes the authorisation decision the most important one the DAO makes. Three practices follow from it:

• Prefer the canonical Superchain bridge over third-party adapters wherever both are options.
• Review every adapter before authorising it, and publish the review.
• Keep the number of authorised bridges as small as the product allows. Each one is an independent way supply could be created improperly.

Verification

The contract has 323 automated tests across the six production contracts and the testnet-only app contracts (pool, sale, gasless router, outbox), two of them randomised property tests that generate operation sequences nobody wrote by hand and assert the invariants survive, including tests that assert the absence of fee, freeze, pause, mint and clawback functions rather than only testing what exists. Static analysis with Slither runs against all six contracts on every verification pass. It found four real issues, now fixed — trapped ether in the paymaster, an ignored return value in the router, and reentrancy exposure in the liquidity lock. The remaining findings are suppressed individually, each with its reasoning recorded, so a reader can disagree with a specific judgement rather than having to trust a clean report. On Base Sepolia the full architecture passed 39 live-chain checks with zero failures.

Neither is a substitute for an independent audit, which has not been performed.

Governance

The Stater DAO governs the protocol at one vote per token. Voting power is measured by ERC-5805 checkpoints rather than by current balance, which matters more than it sounds.

Why checkpoints

Without them, one-token-one-vote is trivially defeated. An attacker borrows a large balance in a flash loan, votes, and repays — all in a single transaction, at almost no cost. Governance decided by whoever can borrow the most for twelve seconds is not governance.

Checkpoints record voting power at each point in time. A Governor reads getPastVotes at a timepoint before the proposal existed, so a balance acquired afterwards carries no weight. The token's test suite includes this exact attack: an address acquires five billion STTR after the snapshot and its past voting power still returns zero.

Delegation

Voting power is opt-in. Tokens do not vote until they are delegated, including delegating to yourself:

delegate(myAddress)     // activate my own voting power
delegate(someoneElse)   // hand my voting power to a delegate; tokens do not move

This is a genuine usability hazard. Holders who never delegate have zero influence without realising it, and a DAO whose holders have not delegated will look inactive regardless of how many tokens exist. Activating delegation belongs in the application's onboarding flow, not buried in documentation.

Delegating to someone else transfers voting power only — the tokens never leave the holder's wallet.

What the DAO decides

• Which bridge contracts are authorised to move supply between chains
• Treasury allocation from the development, grants and marketing buckets
• Grant funding for independent developers
• Protocol parameters and supported networks

The token's clock runs on timestamps (mode=timestamp), so it pairs with a timestamp-based Governor.

Status

Stated plainly, so no reader has to guess which claims are finished and which are intentions.

Verify it yourself

The architecture described above is deployed on Base Sepolia and can be read by anyone. These are testnet addresses and will be replaced at mainnet launch; they are published so the claims in this document can be checked rather than taken on trust.

Every multisig above is 2-of-3. The vesting contract is sealed and holds 15% of supply; the admin multisig holds the token's admin role and no tokens at all. Reading these addresses on a block explorer shows the same balances and the same team split this document states — 70/15/15 across the three partner wallets.

What the testnet run covered

All six contracts were deployed to Base Sepolia and exercised with real transactions — 136 checks in four suites, zero failures. The token and its bridge rails account for 34, the multisig custody model for 42, the paymaster, intent escrow and swap router for 23, and a further 37 come from a script that re-reads the chain afterwards and re-derives every figure from the allocation table rather than trusting the deployment log. The escrow's five-minute challenge window was waited out rather than skipped, because on a real chain there is no skipping it. The run covered the full supply mint, the absence of any fee, freeze, pause or mint function in the deployed ABI, a gasless permit() signed by a wallet holding no ETH, delegation and the flash-loan defence, ERC-7802 burn-and-mint with global supply conserved, a zero-supply remote deployment, and the limits on the admin role.

Two results are worth singling out. A wallet holding zero ETH signed an approval and a relayer moved its tokens — the mechanism the whole gas-abstraction design rests on. And an address that acquired five billion STTR after a governance snapshot returned zero past voting power, which is the flash-loan attack the checkpointing exists to defeat.

The deployed bytecode matches this source, mint caps and all. The token, the vesting contract and the liquidity lock are verified on Blockscout, so the code behind those addresses can be read directly rather than taken on description. The paymaster, escrow and router were exercised against a dedicated test token rather than the canonical one, since the canonical supply sits in the Safes.

The testnet app

A second, separate deployment on Base Sepolia runs the public app at staterdao.com. It has its own token, so nothing a visitor does touches the canonical testnet supply held in the Safes above.

Getting test STTR. Two ways. StaterFaucet hands out 1 STTR per wallet every 24 hours, free: the relayer sends the claim with claimFor and pays the gas, so a wallet holding no ETH can claim, while the cooldown and a daily budget of 1,000 STTR are enforced by the contract itself, not the page. For more, StaterTestnetSale sells test STTR for Base Sepolia ETH at the STTR/ETH pool's current price, up to 0.05 ETH per purchase. It mints nothing — STTR has a fixed supply — but sells from a stock of existing tokens deposited into it. Half of every payment goes into the STTR/ETH pool, paired with STTR from the stock at the pool's own ratio so the price does not move; the sale keeps the LP shares and has no function that moves them, so that liquidity is permanent. The other half goes to the relayer, so people buying test tokens pay for the gas it spends on everyone's orders. Buying there and selling into the pool always loses the pool's fee, so the sale cannot be used to drain the pool.

A pool of real testnet ETH. StaterPair is a constant-product pool in the Uniswap v2 design. Its ETH side is the WETH predeploy on Base, which cannot be minted — its supply is exactly the ETH deposited into it — so the pool holds real Base Sepolia ETH. It was seeded with 0.95 ETH at 1 ETH to 1,000,000 STTR. Anyone can add liquidity and receives LP shares that redeem pro rata, and the 0.3% swap fee stays in the pool for them. The first 1,000 shares are burned to defeat the first-depositor inflation attack, and reserves are tracked explicitly so a donation cannot move the price.

Swaps to other assets and EVM chains. STTR can be bought with ETH, sold for it, or sold for five demo tokens — dUSDC, dUSDT, dDAI, dWBTC and dLINK — each with its own pool. The demo tokens have a fixed supply and no mint, so the only way to get one is to sell STTR for it. A sale can name any of thirteen EVM testnets as its destination. Delivery there is simulated: a demo bridge records the chain a real bridge would have used and pays the wallet on Base Sepolia. It keeps nothing, and the app says so before every such sale.

Real SOL and SUI. STTR can also be sold for real SOL on Solana devnet or real SUI on Sui testnet. StaterOutbox sells the STTR for ETH in the pool and holds that ETH against an order naming the holder's Solana or Sui address. The relayer pays the coin at market price from its own wallet on that chain, records the payment's transaction id on Base, and only then takes the ETH. An order nobody fills within an hour refunds to the holder, and one the relayer cannot pay — an empty wallet, a malformed address — refunds at once. The contract cannot see Solana or Sui, so a dishonest relayer could record a payment made to someone else. That is the trust a holder places in it, and the recorded transaction id is what lets anyone check.

Selling with no ETH. A holder signs an order and an ERC-2612 permit — two signatures, no transaction. A relayer submits them and pays the gas in ETH, and StaterGaslessRouter checks every signed field before paying the relayer its fee in STTR out of the sale. The fee is the gas cost priced at the pool's rate, times 1.5. The relayer decides only whether to submit an order, never what it says: raising the fee, redirecting the proceeds, lowering the minimum or replaying an order all revert. Once it holds 500 STTR in fees it sells them back into the pool for ETH, so the fees pay for future gas.

Verified live: a wallet holding exactly zero ETH sold 100 STTR, received ETH, paid a 5.28 STTR fee and sent no transaction of its own. A replay, an underpriced fee and a forged signature were refused, and four orders submitted at the same moment all settled. A sale of 100 STTR for SOL delivered 0.002253939 SOL to a brand-new Solana address and settled on Base with that payment recorded.

This is the gas-abstraction design working end to end, in a narrower form than the paymaster: one relayer, run by the project, for one kind of transaction. It could refuse to relay an order; it cannot change one. The paymaster path through public ERC-4337 bundlers is still to be integrated.

Risk factors

These are specific to this project. They are not a substitute for independent diligence.

Vesting is proven on testnet, not on mainnet. The team and early-investor allocations, 15% of supply combined, release at 5% per month; the team over 20 months, the investor over 19 after a 5% opening tranche. The contract has been deployed, funded, sealed and released from on Base Sepolia. On mainnet it does not exist yet, so nothing on-chain constrains those tokens today. It becomes a real constraint once the contract is deployed, sealed and its address published — sealing is refused unless the contract already holds every token it promises.

Allocation is designed and rehearsed, not yet live. The custody model — a separate multisig per bucket, a sealed vesting contract and a liquidity lock — has been deployed end to end on Base Sepolia, with every token accounted for. No mainnet address exists yet, so a reader cannot currently verify the split on the chain that will matter.

No independent audit. The six production contracts have 323 automated tests — which also cover the testnet-only playground — and 136 passing live-chain checks, and a static-analysis report whose every finding is triaged in writing, but no third-party security firm has reviewed any of them. The paymaster and intent escrow are the newest and least exercised of the six, and the intent escrow in particular settles optimistically — it cannot see the chain it is paying for, so its safety rests on a solver's bond being worth more than the fill and on someone actually watching. Testing shows the code does what its authors intended; it cannot show the absence of flaws they did not consider.

Most of the liquidity allocation is not locked. Only the portion paired on Uniswap is locked. The rest of the 15% sits in a 2-of-3 multisig for exchange listings and can be moved with two signatures. A launch pool holding a small part of the allocation is also thin, so modest trades can move the price sharply until more liquidity arrives.

Bridges can mint, up to a cap. A bridge is the one component that can create supply, so it remains the most severe technical risk in the design. It is now bounded rather than unlimited: BRIDGE_ROLE on its own mints nothing, each bridge carries a per-24-hour cap the DAO sets explicitly, and a guardian key can cut that cap to zero in a single transaction without a governance vote. A compromised bridge can therefore create at most one cap per 24-hour window — two at the very worst, minting at the close of one window and the open of the next — instead of the entire supply. The risk still scales with the number of bridges authorised, and a cap set carelessly high is the same risk wearing a hat.

The utility depends on integrations that do not exist yet. Selling with no ETH, and selling for real SOL, work on testnets through a relayer the project runs, but gas abstraction on mainnet requires paymaster deployments, and cross-chain movement requires authorised bridges. Neither is live on mainnet. Until they are, STTR's stated utility is demonstrated on a testnet rather than available as a working product.

Deployed code is immutable. The contract cannot be patched after deployment. A flaw found later cannot be fixed in place; it would require a migration.

Network risk. Base is a layer-2 with a centralised sequencer. Outages, reorganisations or policy changes at the network level are outside the project's control.

No market exists. The token is not deployed on mainnet, has no liquidity and no trading history. There is no assurance a liquid market will develop or persist.

Regulatory treatment is undetermined. Depending on jurisdiction and on how the token is marketed and sold, STTR may be treated as a security or another regulated instrument. No determination has been made and no regulatory approval has been obtained anywhere.

Disclaimer

This document describes the design and mechanics of a software contract. It is not an offer to sell or a solicitation to buy any asset, and it is not investment, legal, accounting or tax advice.

Figures in this document describe contract behaviour and stated allocations. They are not projections, forecasts, or representations of future performance. Nothing here should be read as a promise of value, return, listing, or liquidity.

Statements about future plans — integrations, deployments, governance, audits — are intentions at the time of writing, not commitments. They may change or not happen.

Digital assets are volatile and can lose all of their value. Smart contracts can contain flaws that testing and static analysis do not find. Anyone considering acquiring STTR should read the contract source, form their own view, and consult their own advisers.

Compiled with solc 0.8.28, optimiser at 200 runs, EVM target cancun. Base mainnet 8453, Base Sepolia 84532.