Layer 2 blockchain infrastructure as a service

Summary

L2 Protocol operates layer 2 blockchains on behalf of other crypto projects. A project whose coin lives on a chain without smart contract support cannot build lending, staking, governance or any other on-chain application on top of it. L2 Protocol gives such a project its own EVM chain, a bridge back to the original chain, a validator set that secures it, a block explorer, and on-chain governance with a timelock. The project brings a community and a reason for the chain to exist. It does not build or run the infrastructure.

The native coin of every L2 Protocol chain is L2P. It pays for gas, it is what validators and delegators bond as stake, and it is what governance counts when it weighs a vote. Its total supply is fixed at genesis at 166,670,000,000 L2P, divided across eight allocations. There is no mint function and no inflation switch.

Thirty percent of that supply, 50 billion L2P, is not held by anyone. It sits in the ValidatorSet contract and is paid out block by block to the validators securing the chain over approximately ten years, on a schedule the contract enforces. In the other direction, a fixed share of every transaction fee is destroyed on every block, permanently.

Every economic parameter of the chain — the burn ratio, the emission rate, the slashing amounts, the staking minimums, the governance rules themselves — is a value that a proposal can change, and only a proposal can change. Proposals pass a token-weighted vote, then wait in a timelock, then may be executed by anyone. There is no administrative key that bypasses that path.

Three ways exist for a project to qualify for its own chain: be large enough that the demand is self-evident, pay for the service, or win a community election in which every wallet gets one free vote per day.

The problem

A great many crypto assets live on chains that were never designed to run programs. Bitcoin-derived chains, older UTXO chains and a long tail of single-purpose networks hold real value and real communities, and they can move coins from one address to another. What they cannot do is run a contract.

That limitation is not cosmetic. Without smart contracts a project cannot offer staking to its holders, cannot run a lending market, cannot issue an NFT, cannot hold a binding on-chain vote and cannot integrate with the wider DeFi ecosystem in any way that does not route through a custodian. The community around such a coin is left with an asset that can be held and traded, and nothing else.

The obvious remedy is to build a chain. In practice that means forking a client, maintaining consensus code, designing an economic model, recruiting and coordinating validators, deploying and auditing system contracts, standing up an explorer, running RPC infrastructure, building a bridge, and then keeping all of it alive indefinitely. It is a multi-year engineering programme with a permanent operational cost attached, and it is a poor use of the resources of a project whose actual value is its community and its idea.

The alternative most projects reach for is to issue a wrapped token on an existing smart contract chain. That works, and it is a real trade: the project inherits somebody else’s block space, somebody else’s fee market, somebody else’s governance and somebody else’s priorities. The token becomes one of tens of thousands on a general-purpose chain, with no control over the environment it lives in.

There is room between those two options. That is where L2 Protocol sits.

What L2 Protocol is

L2 Protocol is layer 2 infrastructure delivered as a service. A qualifying project receives a chain of its own, operated for it.

What a project gets

• An EVM chain with full smart contract support, its own chain ID, its own RPC endpoint and its own block explorer.
• A bridge between the project’s original chain and the new layer 2, so that holders can move value in both directions.
• A validator set with staking and delegation, so the chain is secured by operators with capital at risk rather than by a permissioned committee.
• On-chain governance with a timelock, so the rules of the chain can change without anyone holding a private key over it.
• A fee burn that removes L2P from circulation on every block.

What the project does not have to do

It does not run nodes, maintain the consensus client, write or audit the system contracts, operate the explorer, or keep the bridge alive. All of that is the service. What the project brings is a community and a reason for the chain to exist.

The design commitments

Three commitments shape every technical decision described in the rest of this document.

Everything is readable. Every number the L2 Protocol sites display is an eth_call against a public endpoint that anyone can make. The burn totals, the governance tallies, the validator statistics and the emission parameters are all read from the chain, not from a database that the project controls. A number that cannot be checked is a claim, and the sites are built so that no number has to be taken on trust.

Nothing has an owner. The economic parameters are governed. The emission pool sits in a contract. The burn address has no key. The governance path has a single audited entry point and no administrative override. Where a privileged address does exist — the staking protector and the governance protector, both of which can pause their subsystem — this document names it explicitly, because a safety mechanism that is not disclosed is a backdoor.

Limits point one way. Where a parameter could be abused, its range is bounded in the contract so that abuse is impossible rather than merely unlikely. The clearest example is the emission rate: its genesis value of 317 L2P per block is also its ceiling. Governance can slow issuance down. It can never speed it up.

How a project gets a chain

A project qualifies in one of three ways. All three lead to the same result: the same chain, the same bridge, the same validator set, the same governance.

4.1 Be popular enough

Projects with a large, active holder base qualify on their own numbers. There is nothing to apply for and nothing to pay. Where the demand for a chain is self-evident, the chain gets built.

4.2 Pay for the service

A project that wants a chain now, and does not want to wait for an election, can pay for it. This buys speed. It does not buy privileges, a different chain, a different validator set or a different governance model.

4.3 Win the community vote

Anyone can submit a project at voting.l2protocol.com. Holders vote for the projects they want to see get a chain, and the projects at the top of the leaderboard qualify.

The election is deliberately cheap to participate in and expensive to game.

• One free vote per wallet per day. The day runs on UTC, so every wallet’s vote resets at the same moment worldwide.
• A signature, not a transaction. A voter signs a short message. Nothing leaves the wallet, no fee is paid, and the site gains no access to the wallet. A signature cannot be forged by a script the way a click can, so a vote is attributable to a wallet without anyone being able to cast it on that wallet’s behalf.
• Anti-farming limits. Votes are counted per wallet and per browser, a small number of votes is accepted per internet connection per day, and connections from VPNs and datacentres are refused. Honest voters in a shared household or office can encounter these limits, which is the cost of making vote farms expensive.
• A live leaderboard. Standings update as votes arrive, from everyone, in public.

At present every vote weighs the same. A future token is planned that will let holders boost their voting power, and the voting site states this on its front page.

4.4 After qualifying

Once a project qualifies, its chain is deployed with its own chain ID, RPC endpoint and explorer, and is added to the network feed that every L2 Protocol site reads. From that moment the chain is public: anyone can connect a wallet, stake, vote and read the burn.

Architecture

5.1 The client

The node software is a fork of geth, the reference Go implementation of Ethereum. The binary is called geth, and everything an operator knows about running an Ethereum node continues to apply. It is distributed as a container image at ghcr.io/l2protocol/l2p.

Two files accompany it. genesis.json, published at static.l2protocol.com, describes the first block and the state the chain started from; a node initialised with the wrong genesis file is on a different chain and will never find a peer. config.toml is the node’s own configuration, of which the values that matter are the network ID (12216), the peer-to-peer listen address, the peer count and, optionally, the RPC host and port.

Because the client is a geth fork, the chain is bytecode-compatible with the EVM. Contracts written for Ethereum deploy without modification, and every tool that speaks to an Ethereum node — Hardhat, Foundry, ethers, web3, wallets, indexers — speaks to an L2 Protocol chain by pointing at the endpoint and the chain ID.

5.2 Consensus

Blocks are produced by an elected validator set on a proof-of-stake-and-authority model. A new block arrives roughly every 1.5 seconds, which works out at approximately 21,038,400 blocks per year. That block time is the unit in which every duration parameter on the chain is expressed: one day is 57,600 blocks and one week is 403,200.

Validators are elected into the active set each epoch by total stake. The number elected is the maxElectedValidators parameter, set to 45 at genesis. Of those, a ceiling on how many actually produce blocks is set by numOfCabinets, 21 at genesis; where fewer validators exist than that ceiling, all of them produce. Being bonded is not the same as being elected, and stake behind a validator outside the elected set earns nothing.

Two rotation parameters, maxNumOfCandidates and maxNumOfWorkingCandidates, allow validators outside the producing set to rotate into producing slots. Both are set to zero at genesis, which is discussed in Section 11.5.

A validator produces one block per turn at genesis (turnLength reads as 1). The parameter accepts longer turns of 3 to 64 consecutive blocks, which is relevant to the anti-MEV fee share described in Section 9.

5.3 Finality

Blocks carry one of two states. Unfinalized means the block is on the chain and, in normal circumstances, will stay there. Finalized means it is settled permanently and cannot be replaced, whatever happens afterwards. Blocks reach finality within a short time of being produced.

Finality is voted on by validators using BLS signatures, which is why a validator node holds two distinct keys: an ordinary consensus account that signs blocks, and a BLS key whose public half is the validator’s vote address. A precompile at 0x…0066 verifies BLS signatures on-chain, which is how a validator proves it holds the private half of its vote key at registration.

For everyday amounts the practical difference between a recent block and a finalized one is small, since a transaction in an unfinalized block has essentially already happened. For large amounts, or where something valuable is handed over in return, waiting for the finalized state is the careful choice.

5.4 System contracts

The rules of the chain live in a set of contracts present in the genesis state at fixed addresses. Each has one responsibility.

Full addresses are in Appendix B. Two standard helpers are also in the genesis state: Multicall3 for batching calls, and an ENS registry whose root owner is preset, supporting a .l2p name space.

The reason for govHub deserves a note. A parameter change does not call the target contract directly. It calls govHub.updateParam(key, value, target), and the hub applies the change. That gives the chain one audited path for every parameter change, rather than a separate setter on each contract with its own access control to get wrong. It also means the governor needs exactly one whitelisted target: the hub itself.

5.5 The chain feed

Every L2 Protocol site reads a single JSON feed rather than hardcoding endpoints:

https://chains.l2protocol.com/chains.json

Each entry carries the chain’s name, chain ID, native currency and decimals, RPC endpoints, block explorers and the addresses of the system contracts on that chain. Integrators are encouraged to read from the feed rather than paste values into their code, so that a second chain does not require a second copy of the integration. The feed is what the project’s own sites read, so it is never the stale copy.

5.6 The bridge

Each chain is deployed alongside a bridge to the network the project’s asset lives on today, so that holders can move value in both directions. Bridge design differs by counterparty chain, since the security model available on a UTXO chain is not the one available on an EVM chain.

The L2P coin

L2P is the native coin of the chain. It is not a contract balance and there is no ERC20 representing it on its own chain, in the same way that ETH is not an ERC20 on Ethereum. It has 18 decimals; one L2P is 10¹⁸ wei.

It has three functions, and they are not separable.

Gas. Every transaction pays a fee in L2P. Part of that fee is destroyed and part is paid to the validator that produced the block. Fees are what make block space scarce and therefore what makes spamming the chain expensive.

Stake. Validators bond L2P as self-delegation in order to join the set. Delegators bond L2P behind a validator they choose. Stake is what a validator loses when it misbehaves, and it is therefore what makes attacking the chain expensive. A chain whose validators have nothing at risk is secured by nothing but good manners.

Voting weight. Governance counts the L2P staked behind an address at the snapshot block of each proposal. Coins bought after a proposal opens carry no weight on it, and coins sitting unstaked in a wallet carry no weight at all.

Supply moves in two directions at once: new L2P is emitted per block to the validators securing the chain, and L2P is burned on every transaction. Both sides are governed parameters rather than constants, and both are described in the sections that follow.

Tokenomics

Total supply: 166,670,000,000 L2P, fixed at genesis.

Every coin that will ever exist was assigned to one of eight allocations in the genesis state. There is no mint function anyone can call, no inflation switch and no way to create a coin that was not accounted for on day one.

7.1 Allocations

• Validator and staking emissions30.0%50.00B
• Future public distribution (locked)17.5%29.17B
• Ecosystem and grants15.0%25.00B
• Team (annual vesting)15.0%25.00B
• Treasury and reserve10.0%16.67B
• Liquidity (phased)6.0%10.00B
• Presale round 1 (under €1M)4.5%7.50B
• Advisors2.0%3.33B

7.2 What each allocation is for

Validator and staking emissions — 50 billion. The largest slice by a wide margin, and it is not held by anyone. It sits in the validatorSet contract and is paid out block by block to the validators securing the chain, and through them to the people who delegate to those validators. It is released over approximately ten years on a schedule the contract enforces. Section 8 sets out the schedule in full.

Future public distribution — 29.17 billion. Locked and reserved for distribution at a later date. Locked means what it says: it is not circulating and it is not being sold into the market today.

Ecosystem and grants — 25 billion. For the projects, tools and integrations built on the chain. This is the allocation that pays for the chain being worth using rather than merely existing.

Team — 25 billion. Vesting annually rather than unlocking at once, so that the people building the protocol are paid over the years during which they keep building it.

Treasury and reserve — 16.67 billion. Working capital and a buffer for what nobody planned for.

Liquidity — 10 billion. Phased in rather than deployed in a single event, so that trading L2P is possible without one deployment setting the price on its own.

Presale round 1 — 7.5 billion. A first round, deliberately small at under one million euro. Keeping an early raise modest relative to the size of the chain keeps the share of supply sold early low, and means the project is not funded principally by the people least equipped to judge the risk. Section 15 covers the regulatory framing of that threshold.

Advisors — 3.33 billion. The smallest allocation, for the people advising the project.

7.3 What “fixed supply” does and does not mean

Three clarifications, because the phrase is routinely oversold in this industry.

It does not mean the number goes down. The fee burn moves coins to an address that nobody controls, permanently out of circulation. Those coins are still counted in the total supply figure. Circulating supply falls; total supply does not.

It does not mean everything is circulating. Most of the supply starts locked, vesting or held in a contract. Emissions arrive over ten years, team coins vest annually, the future public distribution is locked and liquidity is phased. What circulates today is a fraction of the total, and it grows on published schedules rather than on discretionary decisions.

It does mean nobody can print more. The allocations were set in the genesis state. There is no governance parameter that raises the total, and no key that mints.

7.4 Reading these figures honestly

A percentage of a supply says nothing about a price. It says how the coins are divided and roughly when they arrive, which is what a reader needs in order to reason about the rest independently.

The two figures worth watching over time are the emissions, which follow a public schedule that can be checked block by block, and the burn, which runs against them and is driven by how much the chain is actually used. Both are visible on-chain, and neither depends on anyone keeping a promise.

The emission schedule

The 50 billion L2P emission pool is paid out per block on a schedule the validatorSet contract enforces.

8.1 The shape of it

Year one pays nothing. Emission starts at block 21,038,400 rather than at block zero, because the presale runs through the first chain year. Blocks before the start block emit nothing at all, which is why year one is empty rather than partially paid.

Then 317 L2P per block for five years. Approximately 6.67 billion per year.

Then the rate halves to 158 L2P per block for another five years. Approximately 3.32 billion per year.

Then it stops. After the second halving window the contract emits nothing further, because the pool is empty.

8.2 Year by year

The halving lands at block 126,230,400, which is 105,192,000 blocks after emission began. The second window ends at block 231,422,400, by which point the pool is all but empty.

8.3 How the contract does it

Four values drive the entire table, and all four are readable on-chain.

Each block, the contract determines which window it is in, halves the rate once per completed window, and pays the resulting amount to the active validators in proportion to their voting power. Jailed validators receive nothing. Once the pool is empty, or once the window counter passes the maximum, payments stop regardless of anything else.

8.4 What governance can and cannot do to it

The rate, the halving period and the number of halvings are governance parameters, so a proposal that passes and clears the timelock can adjust them within limits the contract enforces:

• the rate may be set anywhere from 1 to 317 L2P per block;
• the halving period may not be shorter than 1,000,000 blocks;
• the number of halvings must stay between 1 and 20.

The first limit is the important one. 317 is the genesis rate and also the ceiling. Governance can slow issuance down and can never speed it up.

What cannot be changed at all is the pool. The 50 billion is what the contract holds, and no parameter can make it pay out more than it has. Governance controls the pace; it does not control the total.

8.5 After emissions end

Validators continue to earn from transaction fees, which is the other half of validator income and the half that does not run out. What ends is the creation of new coins. From that point the only mechanism changing the circulating supply is the burn, which runs in the opposite direction.

Fees and the burn

9.1 What a transaction costs

A fee is gas used multiplied by gas price, and nothing else goes into it.

Gas used is a measure of work. A plain transfer of L2P is always 21,000 gas because it is always the same work. A contract call depends on what the contract does.

Gas price is what is paid per unit of gas, quoted in gwei, where one gwei is a billionth of an L2P.

The chain has a minimum gas price of 0.1 gwei, and while the chain is quiet that is what a user pays. A plain transfer at that price costs 0.0000021 L2P. A block holds roughly 70 million gas, which is thousands of transfers, so a quiet chain has no meaningful competition for block space. Gas prices rise when the chain is busy, because everyone is bidding for room in the same block.

Four things about fees are worth stating plainly because they surprise people on every chain:

• A failed transaction still costs the fee. The network did the work of trying, and that work is what the fee pays for. No coins move and the state reverts.
• An address cannot send its entire balance, because the fee must come out of the same balance.
• The gas limit is what a wallet reserves; the charge is for gas actually used. A transaction that exhausts its limit fails and is charged for the whole limit, because all of it was spent trying.
• The amount sent has no bearing on the fee. Sending one coin and sending a million coins cost the same, because both are the same work.

9.2 Where the fee goes

The chain splits every fee three ways in the block that includes the transaction.

The three shares are expressed in basis points over 10,000 and together may not exceed 100%. Whatever is left goes to the block producer.

The anti-MEV share is designed to discourage a producer from reordering transactions for profit by taxing later blocks in a long turn. It does nothing while a producer’s turn is a single block, which is the genesis configuration, and it is therefore switched off.

9.3 The burn

The burn destination is:

0x000000000000000000000000000000000000dEaD

There is no private key for this address. Coins sent there are gone in the only sense that matters on a blockchain: no signature can ever move them.

Because the burn share is a parameter rather than a constant, it changes only through governance: a proposal calling govHub.updateParam("burnRatio", …) that passes its vote and clears the timelock. No individual can turn the burn up or down.

The burn is usage-driven. A quiet chain burns almost nothing; a busy chain burns a great deal. It is not a schedule that runs whether or not anyone shows up, which means the burn rate is an honest signal of how much the chain is actually being used.

It is not a promise about price. The burn removes coins. What that is worth is a matter for the market.

Every burn figure is published at l2pburn.info, which reads the burn address balance, the burn ratio and the last indexed block directly from the chain, and shows the burn per day. Each figure there can be checked independently against the block explorer.

Staking, delegation and validator economics

10.1 Running a validator

A validator produces blocks. To join the set, an operator bonds L2P as self-delegation, registers the node with its consensus and BLS keys, and stays online.

What it requires. A machine that is always on, because downtime is punished rather than forgiven. A fast disk with room to grow, because the chain writes constantly and reads randomly. A stable connection with the peer-to-peer port reachable from the internet. Someone who watches it, because the chain does not send a message when a node stops.

What it earns. A share of the gas fees on the blocks it produces, minus the portion that is burned and the portion routed to the system reward pot, and block emissions on the schedule in Section 8. The operator keeps a commission on what its delegators earn; the rest is theirs.

What it risks. Two behaviours cost stake, and the amounts are set against the self-stake rather than against pending rewards, which is the point.

A validator must bond seven million L2P of its own before it may run at all. Downtime costs half a percent of that floor; a double sign costs ten percent. These are not fines that can be absorbed as a cost of doing business.

Downtime is measured in missed blocks. Passing misdemeanorThreshold (50 at genesis) redistributes a validator’s pending rewards. Passing felonyThreshold (150) removes it from the set, applies the downtime slash and jails it for downtimeJailTime (2 days).

Double signing — signing two conflicting blocks — is treated as a felony: the larger slash and a 30-day jail. There is no honest reason to do it, so the punishment does not attempt to be gentle.

Slashed stake is taken from self-delegation first. That is why the self-delegation figure matters as much to a delegator as it does to the operator.

Maintenance exists so that an operator can upgrade without being punished for the downtime. maxNumOfMaintaining (3 at genesis) caps how many validators may be in maintenance simultaneously, and at least one producing validator must always remain. maintainSlashScale (2) divides the missed-block count charged when a validator leaves maintenance. Overstaying maintenance costs the operator.

Malicious voting — a finality violation — carries the same penalty as a double sign, but the check that detects it is switched off at genesis. Section 11.5 explains why.

10.2 Delegating

Securing the chain does not require running a node. A delegator sends L2P to the stake hub, naming a validator, and receives stake credit representing a share of that validator’s pool. Rewards are added to the pool, so a delegator’s share grows without any claim transaction.

Delegated stake is at risk. If the validator is slashed, the pool shrinks and so does every delegator’s share. The right mental model is choosing a business partner, not choosing a lottery ticket.

Four things are worth checking before delegating, and all four are published per validator at validators.l2protocol.com:

• Commission — what the validator keeps of a delegator’s rewards.
• Self-delegation — how much of the operator’s own capital is at risk. A validator with nothing of its own to lose is asking delegators to carry all of it.
• Uptime — missed blocks are missed rewards, and enough of them are a slash.
• Elected or not — stake behind a validator outside the elected set earns nothing.

10.3 Undelegating and redelegating

Undelegation is not instant. Stake enters an unbond period of 7 days at genesis, and only after it expires can the coins be claimed. The delay exists so that a validator cannot misbehave and let its backers exit before the slash lands.

Stake can instead be moved directly to another validator without waiting, at the cost of redelegateFeeRate, set at genesis to 2 over a base of 100,000, or 0.002%, paid to the destination validator.

The smallest permitted delegation or redelegation is minDelegationL2PChange, 3,500 L2P at genesis, which keeps dust off the chain.

10.4 Governance weight

Delegated L2P carries governance weight, measured at the snapshot block of each proposal. Staking does not remove a holder from the conversation about where the chain goes next; it is the only thing that puts them in it.

Governance

The chain’s parameters are not owned by anyone. They are changed by proposals that pass a vote and then wait in a timelock before taking effect.

11.1 What a parameter change actually does

The dials governance turns are the economics and the rules of the chain, not the code. Changing one changes what the chain does from the next block onwards, for everybody, without anyone upgrading anything.

Take the burn. Every transaction pays a fee, and a fixed share of that fee is destroyed. Suppose that share stands at 10% and the community concludes that L2P is being issued faster than it is being removed. One proposal, one number, and from the moment it executes every transaction on the chain destroys a quarter of its fee instead of a tenth. Nobody had to agree to it individually, no contract was redeployed, and the validators who now earn less had one vote each on it like everyone else.

Every parameter change is a trade of that shape:

• Raising minSelfDelegationL2P forces anyone running a validator to put more of their own capital at risk. The set becomes smaller and its operators more careful.
• Shortening unbondPeriod returns coins faster after undelegation, and makes it correspondingly easier for a validator’s backers to leave before a punishment lands.
• Raising quorumNumerator requires more of the supply to turn out for a vote to count, which protects against a handful of holders deciding things and, set too high, means nothing passes at all.

The vote is on the trade, not on the number. That is why a proposal’s description matters as much as its value.

11.2 The lifecycle

1. Propose. Anyone holding at least proposalThreshold govL2P (700,000 at genesis) may submit. A proposal is either a parameter change, which is executable, or a signal proposal, which records what the community wants without changing anything by itself.

2. Vote. Voting opens after votingDelay (0 blocks at genesis, so immediately) and stays open for votingPeriod (403,200 blocks, 7 days). Voting weight is the govL2P behind an address at the proposal’s snapshot block, so coins acquired after the proposal opened do not vote.

A voter may vote for, against, or abstain. Abstaining is not the same as not voting: it counts towards quorum without taking a side. A proposal passes when it clears quorum (quorumNumerator, 10% of all govL2P at genesis) and the votes for exceed the votes against. minPeriodAfterQuorum (57,600 blocks, 1 day) keeps voting open for a further period after quorum is reached, so that nothing is pushed over the line at the last second.

3. Queue. A passed proposal is queued into the timelock and cannot execute yet. minDelay is 24 hours at genesis, with a ceiling of 14 days. The delay is deliberate: it gives everyone who disagrees time to react, exit or organise before the change lands.

The governor only accepts whitelisted targets. A proposal calling anything else can pass its vote and still never execute, which is by design. In practice the only whitelisted target is govHub, for the reason given in Section 5.4.

4. Execute. Once the timelock expires, anyone may execute the proposal. Not only the proposer, and not an administrator. Execution is permissionless, so a passed proposal cannot be quietly dropped.

11.3 govL2P

Voting power is counted in govL2P, held automatically for every L2P staked. It is minted on delegation and burned on undelegation, it cannot be transferred to anyone, and it exists for no purpose other than governance. Coins sitting unstaked in a wallet carry no weight at all.

This ties governance weight to capital that is locked behind a validator and exposed to slashing, rather than to a balance that can be borrowed for the duration of a vote and returned afterwards.

11.4 What governance can change

Every parameter the chain exposes to a vote is listed in Appendix A, grouped by subsystem: block fees, emissions, block production, maintenance, staking and delegation, punishment, governance itself, and the system reward operators. Each carries its genesis value and the range the contract will accept.

Two conventions are worth internalising. Percentages are written as whole numbers over a base, and the base is not the same everywhere: block fee shares and commission run over 10,000, so 1000 is 10%, while the redelegation fee runs over 100,000, so 2 is 0.002%. Durations are always in blocks, at 1.5 seconds per block.

Every range is enforced by the contract. A value outside it can pass its vote and then fail on execution. Several parameters are also bound to each other — the two slash amounts, the two jail times, the two downtime thresholds and the three fee shares must each stay in the correct order — so changing one of a pair usually means proposing the other as well.

11.5 Progressive activation

Three things ship deliberately inactive. None is an oversight, and each has a moment at which it should be switched on.

Governance itself. The governor accepts nothing at all until 35,000,000 govL2P exists, which is five fully staked validators. Until that point no proposal can be submitted, which prevents a small amount of stake from steering the chain in its first weeks. It opens on its own the moment the threshold is passed. Nobody has to unlock it and nobody can unlock it early.

Candidate rotation. maxNumOfCandidates and maxNumOfWorkingCandidates are both zero. Below 21 validators the rotation code is never reached, so setting values now would change nothing observable, and choosing them later means choosing them against real participation. This must be configured before the set grows past 21 validators: after that point every validator outside the top 21 is permanently excluded from block production until it is.

Malicious vote slashing. enableMaliciousVoteSlash is false, so evidence of a finality violation is rejected. Verifying that evidence is intricate, and a fault in that verification punishes honest validators. Double-sign slashing protects the chain in the meantime. It is intended to be enabled once losing two validators simultaneously is survivable for the set.

All three depend on governance, and governance depends on the staking threshold. The order is not accidental: the chain decentralises as the stake securing it grows, rather than on a calendar.

The application suite

The protocol is accompanied by a set of applications. Each is public, each reads from the chain, and none is required in order to use the chain.

Behind these sit the services that tooling talks to: the RPC endpoint at rpc.l2protocol.com, the chain feed at chains.l2protocol.com, static files and the genesis at static.l2protocol.com, and validator profiles at validator-directory.l2protocol.com.

For developers

13.1 Connecting

Anything that talks to an EVM chain needs the same four values.

In Hardhat:

networks: {
  l2protocol: {
    url: "https://rpc.l2protocol.com",
    chainId: 12216
  }
}

In Foundry, foundry.toml:

[rpc_endpoints]
l2protocol = "https://rpc.l2protocol.com"

Where the tooling allows it, read these values from the chain feed rather than pasting them, so that a second chain does not require a second integration.

13.2 RPC

The RPC is standard JSON-RPC over HTTPS, so anything that speaks Ethereum speaks to it. Reading the chain needs no wallet and no key.

curl -s https://rpc.l2protocol.com \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

Every read that the project’s own sites perform — including the governance tallies and the burn totals — is an eth_call against this public endpoint, and anyone can make the same call.

13.3 RPC or the explorer API

Both answer questions about the chain and they are good at different things.

The RPC is the chain itself, right now. Use it for current state, for anything needed at the head of the chain, and for sending transactions.

The explorer API is indexed history. Use it for anything that would take many RPC calls to assemble: an address’s transaction list, a token’s holders, statistics over time. It runs a block or two behind the head, and /api/explorer/status reports exactly how far.

13.4 Deploying and verifying

Contracts deploy exactly as they do on any EVM chain. Source verification is published through the explorer so that others can read and call a contract without trusting its author’s description of it. The chain also ships an ENS registry with a .l2p name space, so that addresses can carry human-readable names.

13.5 Reading a parameter

Everything the sites display can be read directly. For example, the current burn ratio is an eth_call against the validator set:

curl -s https://rpc.l2protocol.com \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call",
       "params":[{"to":"<validatorSet>","data":"<burnRatio selector>"},"latest"]}'

Security, operations and user safety

14.1 Protocol security

The chain’s security rests on stake at risk. A validator bonds seven million L2P of its own before it may run, and loses a fixed amount of that stake for downtime and a much larger amount for a double sign. Slashing comes out of self-delegation first, so the operator absorbs the loss before its delegators do. The unbond period prevents a validator’s backers from exiting between the misbehaviour and the penalty.

Governance is protected by structure rather than by trust: a single audited path through govHub, a whitelist that admits only that path, a quorum, a minimum period after quorum, a timelock, and permissionless execution.

The two pause capabilities described in Section 11.4 are the exception, and they are disclosed rather than hidden.

14.2 Operational infrastructure

The public services run on managed Kubernetes with a hardened network perimeter, dedicated database and analytics nodes on a private network, and a tunnelled ingress so that no origin host is directly exposed to the internet. Deployments are automated and zero-downtime.

Nothing in this stack is load-bearing for the chain itself. The chain is secured by its validator set, not by the project’s servers. If every L2 Protocol website went offline tomorrow, the chain would continue producing blocks and anyone could still transact against it with their own node or any public endpoint.

14.3 User safety

Phishing is the most common way holders lose money in this industry, and it does not require any flaw in the protocol.

The complete list of official sites and channels is in Appendix C. Anything not on that list is not official: there is no partner portal and no special page sent privately.

Four habits protect against nearly all of it. Read the address bar rather than the page, because a fake site is a perfect copy apart from its address. Check the whole domain from the right, since l2protocol.com.example.net is not the same site and neither are l2-protocol.com or l2protocol.io. Use a bookmark once on a real site, which defeats search adverts and typosquats in one move. Treat search results with suspicion, because paid adverts above the real result are routine.

None of those words describes anything the protocol does. Anyone unsure should open a ticket at support.l2protocol.com with the link in question and wait for a reply. That costs an hour. Guessing has cost other people everything they had.

Regulatory position

L2 Protocol is operated through a company structure established in the Netherlands and is therefore within the scope of the European Union’s Markets in Crypto-Assets Regulation (MiCAR).

The first presale round is sized at under one million euro over a twelve-month period. Under MiCAR, an offer to the public of a crypto-asset other than an asset-referenced token or an e-money token that does not exceed EUR 1,000,000 over twelve months falls outside the obligation to publish a regulated crypto-asset whitepaper and to notify a competent authority. Round 1 is scaled to that threshold deliberately: the intent is a modest raise relative to the size of the chain, keeping the share of supply sold early low.

This document is published voluntarily for transparency. It is not a MiCAR crypto-asset whitepaper within the meaning of Title II of the Regulation, it has not been notified to or approved by any competent authority, and its publication does not itself bring the offer within scope.

L2P is a native coin of a public permissionless blockchain, used for transaction fees, staking and governance. It does not reference the value of any other asset or basket of assets and is not redeemable at par against a claim on the issuer, so it is neither an asset-referenced token nor an e-money token.

Risk factors and disclaimer

16.1 Risk factors

Anyone considering acquiring, staking or building on L2P should weigh at least the following.

Market risk. The value of L2P may fall, including to zero. The burn removes coins from circulation; it does not create demand, guarantee liquidity or support a price. Nothing in this document is a forecast.

Liquidity risk. The liquidity allocation is phased in rather than deployed at once. Market depth may be thin, and there is no guarantee that L2P will be listed on any particular venue or remain listed.

Supply risk. A substantial share of the total supply is locked, vesting or held in a contract at the time of writing. Circulating supply grows over time on published schedules. Future unlocks and the future public distribution will increase the coins available to the market.

Slashing risk. Delegated stake is exposed to the behaviour of the validator it backs. A slashed validator’s pool shrinks and every delegator’s share shrinks with it. Undelegation is subject to the unbond period, during which the stake cannot be moved or sold.

Validator concentration risk. Early in a chain’s life the set is small. Until the set grows, a small number of operators produce most blocks, and the governance activation threshold of five fully staked validators is a floor, not a guarantee of decentralisation.

Governance risk. Governance can change the economics of the chain, including the burn ratio, the emission pace, the slashing amounts and the rules of governance itself, within the ranges the contracts enforce. A holder who does not stake has no vote on any of it. A holder who does stake may be outvoted.

Privileged address risk. Two addresses can pause staking and governance respectively. They are a safety mechanism and they are also a trust assumption.

Smart contract risk. The system contracts, the bridge and any application deployed on the chain may contain defects. A defect in a bridge is the highest-consequence failure mode in any multi-chain system.

Bridge and counterparty chain risk. A bridge depends on assumptions about both chains it connects, including their finality. A reorganisation, halt or consensus failure on either side can affect assets in transit.

Operational and key-management risk. Validator operators can lose funds through their own configuration errors, of which running two nodes on the same consensus key is the most expensive. Users can lose funds through phishing, seed-phrase compromise or sending to the wrong address. None of these is recoverable.

Regulatory risk. The regulatory treatment of crypto-assets is developing in every jurisdiction. Changes in law or in its interpretation may affect the protocol, the offer, the availability of the applications, or a holder’s ability to acquire, hold or dispose of L2P.

Key person and execution risk. The protocol is developed by a small team. Delivery of anything described as planned depends on continued development, funding and the growth of a validator set that is not under the project’s control.

Technology risk. The client is a fork of an actively developed upstream. Upstream defects, network attacks and novel consensus-level exploits remain possible.

16.2 Disclaimer

This document is published for information only.

It is not investment, financial, legal, tax or accounting advice, and it must not be relied on as any of those. It is not an offer to sell, nor a solicitation of an offer to buy, any asset, security or financial instrument, in any jurisdiction in which such an offer or solicitation would be unlawful. It is not a prospectus and it is not a MiCAR crypto-asset whitepaper within the meaning of Title II of Regulation (EU) 2023/1114.

Statements about future functionality, timelines or activation of protocol features are forward-looking. They reflect current intentions and are subject to change without notice. They are not commitments and no reliance should be placed on them.

Every quantitative statement in this document about the live network reflects the protocol’s configuration at the time of writing. Parameters can be changed by governance. The chain is the record. Where this document and the chain disagree, the chain is correct. Readers are encouraged to verify every figure themselves, and Sections 9, 11 and 13 describe how.

No representation or warranty, express or implied, is given as to the accuracy or completeness of this document. To the fullest extent permitted by law, no liability is accepted for any loss arising from its use.

Acquiring crypto-assets involves substantial risk, including the risk of losing everything invested. Anyone considering it should form their own view, and should take independent professional advice appropriate to their circumstances and their jurisdiction.

Roadmap

Phase 1 — Genesis and bootstrap. Chain live at chain ID 12216. System contracts deployed in the genesis state. Explorer, RPC, chain feed, staking site, governance site, voting site, burn site, network status and support live. Presale round 1 running through chain year one. Emissions do not start until block 21,038,400.

Phase 2 — Validator set growth. Recruit and onboard independent validator operators. Governance unlocks automatically at 35,000,000 govL2P, five fully staked validators. Emissions begin at the start block.

Phase 3 — Governance activation. First parameter proposals. Configure candidate rotation before the set passes 21 validators, which is a hard sequencing requirement rather than a preference. Enable malicious vote slashing once losing two validators simultaneously is survivable. Depends on governance.

Phase 4 — Chains for other projects. First community-elected chain deployed end to end: chain, bridge, explorer, validator set, governance. Repeat via all three qualification routes.

Phase 5 — Ecosystem. Deploy the ecosystem and grants allocation against applications built on the chains. Phase in liquidity. Future public distribution.

Parameter reference

All values are the genesis configuration. Every one of them is readable on-chain and changeable only by a proposal that passes its vote and clears the timelock, within the range shown. Durations are in blocks at 1.5 seconds per block: one day is 57,600 blocks, one week is 403,200.

Block fees

The three shares are taken from the same fee and together may not exceed 10,000 (100%). The remainder goes to the block producer.

Emissions

Block production

Maintenance

Staking and delegation

Punishment

Governance

Proposals may only ever call govHub. That is fixed at genesis and is not a parameter.

System reward operators

System contracts

Addresses on the L2 Protocol chain (chain ID 12216). These are also published in the chain feed, per chain; integrations should read them from the feed rather than hardcode them.

curl -s https://chains.l2protocol.com/chains.json | jq '.[0].contracts'

Official links

If a site is not on this list, it is not official. There is no exception, no partner portal and no special page sent privately.

Sites

Services

Community

Cloned Telegram groups and Discord servers are the most common impersonation in this industry. Join through the links above, not through a link sent by someone or an invite you were added to.

Glossary

BLS key

The key a validator uses to sign finality votes, distinct from the account that signs blocks. Its public half is the validator’s vote address.

Burn address

0x…dEaD, an address with no private key. Coins sent there can never be moved by any signature.

Cabinet

The subset of elected validators that actually produces blocks, capped by numOfCabinets.

Commission

The share of a delegator’s rewards that the validator keeps.

Delegation

Bonding L2P behind a validator to share in what it earns and in what it risks.

Double sign

Signing two conflicting blocks. Treated as a felony, with the largest slash and the longest jail.

Elected set

The validators chosen each epoch by total stake, capped by maxElectedValidators. Stake behind a validator outside this set earns nothing.

Emission

New L2P created per block and paid to validators, on the fixed schedule in Section 8.

Epoch

The interval at which the validator set is re-elected.

Felony

The severe class of misbehaviour: a double sign, or a malicious finality vote once that check is enabled.

Finalized

A block that is settled permanently and cannot be replaced.

Gas

A measure of computational work. A fee is gas used multiplied by gas price.

govL2P

Non-transferable voting power, minted automatically for every L2P staked and burned on undelegation.

Jail

A period during which a punished validator produces no blocks and earns nothing.

Misdemeanor

The lesser class of misbehaviour: enough missed blocks to have pending rewards redistributed.

Quorum

The share of all govL2P that must vote for a proposal’s result to count.

Redelegation

Moving stake directly from one validator to another without waiting out the unbond period, at the cost of a small fee.

Signal proposal

A proposal that records what the community wants without changing any parameter by itself.

Slashing

Cutting a validator’s stake as a penalty, taken from self-delegation first.

Snapshot block

The block at which voting weight is measured for a proposal. Coins acquired afterwards do not vote on it.

Stake credit

A delegator’s share of a validator’s pool.

Self-delegation

The L2P a validator bonds of its own, and the first thing slashed when it misbehaves.

Timelock

The mandatory delay between a proposal passing and anyone being able to execute it.

Unbond period

The waiting time between undelegating and being able to claim the coins.

wei

The smallest unit of L2P. One L2P is 10¹⁸ wei.