Solayer (LAYER)

Solayer: Solana Restaking Expands Into a Separate Execution Network

Solayer began as a Solana-native restaking protocol for allocating stake-weighted blockspace and validator services. Its current design also includes Solayer Chain, sSOL, governance through LAYER, and a proposed hardware-accelerated execution layer, creating a wider system than a conventional liquid-staking product.

From Solana restaking to a broader protocol stack

Solayer’s original architecture focused on restaking within the Solana ecosystem. Users deposit SOL or supported liquid-staking assets and receive Solayer representations that can be delegated to actively validated services, or AVSs. Those services can use delegated stake to obtain stake-weighted quality of service, including improved access to blockspace and transaction inclusion. This is different from ordinary liquid staking, where the primary purpose is to represent a validator position while preserving liquidity.

The project’s newer documentation presents Solayer as a stack with several layers: Solayer Chain as infrastructure, sSOL as a liquid staking asset, and additional products such as sUSD and Solayer Pay. These products are project plans and product descriptions, not independent evidence that every component is live, widely used, or economically sustainable. The practical question for users is which Solayer functions are active on the relevant date and which remain subject to future design changes.

How sSOL and AVS delegation are intended to work

sSOL represents deposited SOL on Solana and is designed to preserve liquidity while the underlying assets earn staking-related rewards. Solayer’s documentation describes a flow in which a user deposits SOL, receives sSOL, and may then delegate that sSOL to an endogenous AVS. The delegated position can be represented by an additional SPL token, allowing a dApp to coordinate stake allocation without requiring each user to operate a validator.

The model creates dependencies beyond Solana’s base staking system. Returns and usability can depend on validator performance, delegation rules, AVS incentives, liquidity in secondary markets, and the ability of each service to deliver the promised blockspace or verification function. Earlier Solayer architecture documentation also describes operator-specific penalties and the possibility that malicious or failed operators could put delegated deposits at risk. Those risks are distinct from the risks of holding ordinary SOL or a standard liquid-staking token.

Solayer Chain and the verifier model

Solayer’s current technical documentation describes Solayer Chain as a separate execution environment using a sequencer and a stake-weighted verifier set derived from a Solana contract. For each proposed block, selected verifiers re-execute transactions, compare a resulting state-diff hash with the sequencer’s declared hash, and sign when the results match. A block is finalized after signatures representing at least 51% of the verifier stake are collected and aggregated with BLS signatures.

The design includes recovery procedures for missed quorum or an unresponsive sequencer. Documentation states that a failed round can be retried, followed by reorganization and sequencer rotation if the required threshold is not reached. It also describes a challenge process in which an incorrectly signed malformed block may lead to slashing and verifier removal. These are stated protocol mechanisms; their real-world security depends on implementation quality, validator diversity, operational monitoring, and the economic assumptions behind the stake threshold.

What LAYER does

LAYER is described by Solayer as both the governance token for its protocol suites and the native token planned for Solayer Chain. The documented governance role includes voting on protocol upgrades and ecosystem initiatives. The tokenomics page also describes future or design-dependent uses such as network gas, participation in proof-of-stake consensus, and rewards for verifiers. Those future uses should not be treated as established utility unless the relevant network functions and contracts are live and available to users.

The project documentation states a maximum supply of 1 billion LAYER and describes allocations for community and ecosystem activity, core contributors, investors, and the foundation. It also outlines different vesting arrangements, including cliffs or linear vesting for several categories. Unlock schedules can affect circulating supply, governance concentration, and potential sell-side pressure, so supply analysis requires checking the live contracts and the latest official distribution records rather than relying only on the original tokenomics document.

Governance and upgrade control

Solayer uses Realms for proposal and voting workflows. Its governance documentation says LAYER holders deposit or lock tokens to obtain voting power, with weight corresponding to the amount committed. Community proposals can address tokenomics and network upgrades, while council voting is reserved for wallets holding a council token and is described as a mechanism for urgent fixes or routine operations.

The documented process gives the core team a role in drafting proposals, followed by a voting period of up to six days, a stated 70% approval threshold, and a 12-hour cool-off before execution. This makes governance more than a passive token label, but it does not by itself prove broad decentralization. Concentrated token holdings, council privileges, proposal control, voter participation, and the ability to execute on-chain instructions remain material questions for evaluating practical control.

Users, dependencies, and open questions

The intended users span several groups: SOL holders seeking a liquid staking position, decentralized applications seeking stake-weighted service quality, developers building on Solayer Chain, validators and verifiers, and LAYER holders participating in governance. Each group depends on a different part of the system. A staker depends on custody and redemption mechanics; an AVS depends on delegated stake and validator operations; a chain user depends on sequencer and verifier availability; and a governance participant depends on functioning voting contracts and transparent proposal execution.

Solayer therefore should be assessed as a collection of connected systems rather than as a single staking contract. Important unresolved areas include the operating status of proposed products, the distribution of decision-making power, the degree of verifier and sequencer decentralization, the treatment of operator or AVS failure, and the relationship between LAYER demand and actual network usage. The project’s public repositories and documentation provide useful implementation and governance references, but documentation alone cannot establish adoption, profitability, or long-term security.

Key takeaways

• Solayer combines Solana-native restaking, liquid staking through sSOL, AVS delegation, governance, and a separate Solayer Chain design.
• sSOL is intended to represent deposited SOL while remaining usable for DeFi or delegation, but its risk profile includes validator, AVS, liquidity, and redemption dependencies.
• Solayer Chain uses a sequencer and stake-weighted verifiers that re-execute selected blocks and finalize them after a stated 51% stake threshold.
• LAYER currently has a documented governance role, while gas, verifier rewards, and consensus participation are described as future or design-dependent uses.
• Governance uses Realms, with token-based voting, a stated 70% approval threshold, and a council mechanism for some urgent or routine decisions.
• The main analytical gap is not the project’s stated architecture but the extent to which each component is live, decentralized, independently tested, and used.

Risks and open questions

• Restaking and AVS participation can introduce operator, service, slashing, smart-contract, and redemption risks beyond ordinary SOL staking.
• The verifier and sequencer model may depend on sufficient stake concentration, reliable implementation, and effective failure recovery; documentation does not establish real-world resilience.
• LAYER vesting and allocation schedules may affect circulating supply and governance concentration as tokens unlock.
• The project describes several future or design-dependent LAYER utilities, so current token demand may not match the full scope of the proposed ecosystem.
• Governance power may be concentrated among large token holders, council participants, or proposal authors; public documentation does not by itself quantify effective control.
• The availability, liquidity, and production status of Solayer Chain, sUSD, Solayer Pay, and related products should be verified before treating them as established sources of usage.