Under the hood of flow.lease
flow.lease combines liquid staking, validator voting, and full on-chain governance in one smart contract architecture.
Protocol Architecture
flow.lease is fully executed by deterministic smart contracts deployed on the Waves blockchain. All protocol logic, fund management, leasing operations, voting, and emergency slashing are performed directly on-chain without reliance on external systems for critical operations.
The system consists of the following components:
Smart Contracts
The smart contracts perform all core operations:
Handle WAVES deposits and issue
fWAVEStokens.Process withdrawals, burning
fWAVESand releasing WAVES after settlement cycles.Manage validator registration, deregistration, and validator metadata.
Execute leasing allocations based on voting results.
Handle regular voting for validator selection using FLOW tokens.
Handle emergency voting for validator slashing, triggered by liquidity providers.
Apply the administrative fee processing.
The contracts are immutable, non-upgradeable, fully auditable, and enforce protocol logic autonomously.
Voting System
Validator selection is governed by FLOW-based voting:
FLOW tokens must be locked for a specified number of leasing cycles.
Longer lock durations increase voting power according to a square-root weighting function.
Voting weights are recalculated for each new leasing cycle.
FLOW tokens cannot be transferred while locked, preventing vote double-spending.
This design eliminates flash attacks, vote manipulation, and vote buying, ensuring vote integrity.
Leasing Rebalancing
WAVES delegation to validators is updated at regular leasing intervals (e.g. every 1000 blocks).
Validator allocations are recalculated based on the latest voting snapshot at the beginning of each cycle.
Pending withdrawal requests are considered during rebalancing to guarantee liquidity availability.
Each validator’s lease is updated atomically to its target allocation.
Emergency Voting and Slashing
An emergency governance layer protects liquidity providers:
Liquidity providers holding fWAVES can initiate emergency votes if validators fail to distribute rewards or violate payout schedules.
Emergency votes are weighted by fWAVES balances.
If emergency votes exceed the configured threshold, the validator is forcibly deregistered and its locked FLOW collateral is burned.
The validator immediately loses its leasing allocation.
Reward Distribution and Compounding
Validator rewards are directly accumulated into the protocol contract.
The value of fWAVES automatically increases after each reward distribution.
There are no manual claiming operations required.
The protocol supports multi-asset reward distributions if supported by validators.
Withdrawal Process
Withdrawals are executed in two stages to ensure predictable liquidity management:
Request phase: The user burns fWAVES and reserves the corresponding WAVES amount.
Processing phase: After the next leasing cycle completes, the reserved WAVES are unlocked and made available for withdrawal.
Backend Indexer and API
A non-critical off-chain indexer system reads on-chain data to provide:
Real-time analytics.
Leasing cycles history.
Liquidity pool balances.
Validator states and metadata.
Voting data and emergency vote aggregation.
REST API endpoints for user interfaces, explorers, and third-party integrations.
The indexer has no control over funds or protocol operations. All state transitions are enforced fully on-chain.
Summary Execution Flow
Users deposit WAVES and receive fWAVES.
Validators register by locking 100 FLOW and submitting metadata.
FLOW token holders vote for validators by locking tokens.
Leasing is rebalanced according to voting weights each cycle.
Validator rewards are automatically compounded into the protocol.
Liquidity providers request and process withdrawals according to cycle schedules.
Emergency voting allows liquidity providers to enforce validator slashing if necessary.
Last updated