Summary
This proposal introduces an inactivity-based token redistribution mechanism in which dormant balances are transferred to a protocol treasury after a defined inactivity period (e.g. 5 years), based strictly on on-chain verifiable activity.
The mechanism is not intended as confiscation, but as a structured recovery of assets that are no longer under user control (lost wallets), improving long-term economic efficiency and reducing permanently inaccessible supply.
Minimal Activity (Heartbeat Mechanism)
Resetting the inactivity timer does not require moving the balance or performing a meaningful transaction. Any minimal on-chain activity is sufficient to prove wallet control.
This includes:
• small-value transactions
• self-transfer operations
• staking or governance interactions
• optionally zero-value “heartbeat” transactions (proof-of-life)
The sole purpose is to confirm that the private key remains actively accessible and under user control, not to enforce economic activity or fund movement.
Treasury Allocation
Funds accumulated in the treasury are redistributed per epoch to:
• Validators
• Delegators (Nominators)
• Developers (via algorithmic allocation under governance parameters)
Developer selection and funding decisions are determined through a decentralized on-chain governance system.
Motivation
In most blockchain systems, inactive or lost funds:
• remain permanently locked
• reduce effective circulating liquidity
• create persistent “dead supply”
This proposal aims to:
• reintroduce lost or dormant liquidity into the ecosystem
• strengthen network incentives for validators and delegators
• fund long-term protocol development sustainably
• improve capital efficiency without increasing total supply
Core Mechanism
All user-initiated on-chain transactions are treated as valid indicators of wallet control and reset the inactivity timer.
This includes:
• transfers
• staking actions
• governance interactions
• claim transactions
A claim transaction is explicitly defined as proof of wallet control, demonstrating that the private key remains actively accessible by the user. It is treated as a standard on-chain action and is equivalent for inactivity tracking purposes.
- Inactivity Tracking
Each account tracks:
mapping(address => uint256) public lastActivity;
The inactivity timer is updated whenever a valid on-chain transaction is performed.
Only on-chain verifiable actions are considered valid activity.
- Inactivity Threshold Rule
If:
block.timestamp - lastActivity[user] >= 5 years
Then:
• the wallet is classified as inactive
• the balance is moved to a protocol-controlled escrow state
3. Sweep Logic
function _moveToEscrowIfInactive(address user) internal {
uint256 inactivity = block.timestamp - lastActivity[user];
if (balance[user] == 0) return;
if (isInEscrow[user]) return;
if (inactivity < inactivityPeriod) return;
uint256 amount = balance[user];
balance[user] = 0;
escrowBalance[user] += amount;
isInEscrow[user] = true;
emit EnteredEscrow(user, amount);
}
Treasury Redistribution Model
Funds accumulated in the treasury are distributed per epoch with caps.
Proposed allocation:
• 45% Validators
• 25% Delegators (Nominators)
• 30% Development Fund (governance-defined allocation)
Treasury Safety Constraints
To avoid centralization and governance abuse:
• Maximum allocation per category per epoch (hard cap)
• Time-locked governance execution (delay before fund movement)
• No single proposal may exceed predefined treasury limits
Developer Governance System
A decentralized governance system determines:
• developer grant recipients
• funding priorities
• ecosystem roadmap decisions
Governance model includes:
• token-weighted voting
• proposal-based funding rounds
• time-locked execution for security
Economic Flow
User activity updates lastActivity
Inactivity threshold is reached
Wallet is marked inactive
Funds move to escrow
Treasury receives funds
Treasury redistributes via staking rewards, delegation rewards, and development grants
Expected Effects
Positive:
• reduction of dead supply
• increased effective liquidity
• sustainable protocol funding
• stronger validator and delegator incentives
Risks:
• perception of ownership loss
• governance capture risk
• inactivity classification edge cases
• regulatory sensitivity
Governance risk mitigation
To reduce political dependency and behavioral distortion in developer funding, the system incorporates the following design principles:
• Governance defines funding rules and budget envelopes, not individual recipients
• A portion of developer funding is distributed via algorithmic, usage-based metrics rather than direct voting
• Rewards are delayed and milestone-based to prevent short-term optimization
• Evaluation uses multiple signals (e.g. commits, usage, audits, adoption) to avoid single-metric gaming
• Funding is partially reputation-weighted instead of punitive, focusing on future eligibility rather than direct penalties
• Governance acts as a policy layer, while allocation is partially automated to reduce centralization risk
Threat Model
Inactivity gaming attempts (minimal transactions to reset timer)
Governance capture risk (treasury control concentration)
Market shock risk from large treasury redistributions
Design Considerations
To ensure fairness and clarity:
• inactivity is strictly defined by on-chain activity
• claim is treated as a normal transaction
• UI warnings must precede inactivity threshold
• governance execution must include delays and caps
• treasury distribution is strictly bounded
Key Idea
Idle capital is not destroyed, but reclassified as lost and gradually reintegrated into the ecosystem under transparent, rule-based governance.
Ecosystem Funding Flow
The protocol redistributes value generated by active usage into ecosystem maintenance and development.
Each epoch, protocol revenue is allocated between validators, existing infrastructure, and a development fund that supports ongoing and new project creation.
Funding allocation is based on a combination of on-chain usage metrics and protocol-defined rules, ensuring that successful and actively used projects naturally receive greater support over time.
This creates a self-sustaining feedback loop where ecosystem usage directly contributes to continued development and long-term growth.
Summary
The system aligns incentives so that value generated within the ecosystem is continuously reinvested into maintaining and expanding it, without requiring manual allocation decisions for each individual project.
Optional Extensions
Treasury Buffer System
• smooths reward distribution
• reduces volatility
• stabilizes staking incentives
Emission Floor
• ensures minimum validator rewards
• maintains network security
Adaptive Emission
Emission adjusts based on:
• staking ratio
• network participation
• treasury balance health
Conclusion
This model transforms inactivity from a passive accounting state into a structured economic recovery mechanism, reinforcing:
• network security
• sustainable development funding
• staking incentive stability
• long-term protocol resilience
Incentive Layer (HODL-friendly extension)
To improve long-term holding incentives without affecting inactivity rules:
- Long-Term Holding Rewards
• reward multiplier based on holding duration
• applied to staking or treasury distributions
• does not affect inactivity timer
- Partial Redistribution to Long-Term Holders
• optional allocation of treasury emissions (10–20%)
• based on snapshot eligibility
• no requirement for active transactions
- Proof of Holding Signal
• minimal interaction to confirm continued ownership
• does not interfere with inactivity logic
Final Summary
This hybrid model improves capital efficiency by reclaiming truly lost assets while preserving incentives for both active participants and long-term holders, resulting in a more resilient and balanced token economy.
Summary
This proposal introduces an inactivity-based token redistribution mechanism in which dormant balances are transferred to a protocol treasury after a defined inactivity period (e.g. 5 years), based strictly on on-chain verifiable activity.
The mechanism is not intended as confiscation, but as a structured recovery of assets that are no longer under user control (lost wallets), improving long-term economic efficiency and reducing permanently inaccessible supply.
Minimal Activity (Heartbeat Mechanism)
Resetting the inactivity timer does not require moving the balance or performing a meaningful transaction. Any minimal on-chain activity is sufficient to prove wallet control.
This includes:
• small-value transactions
• self-transfer operations
• staking or governance interactions
• optionally zero-value “heartbeat” transactions (proof-of-life)
The sole purpose is to confirm that the private key remains actively accessible and under user control, not to enforce economic activity or fund movement.
Treasury Allocation
Funds accumulated in the treasury are redistributed per epoch to:
• Validators
• Delegators (Nominators)
• Developers (via algorithmic allocation under governance parameters)
Developer selection and funding decisions are determined through a decentralized on-chain governance system.
Motivation
In most blockchain systems, inactive or lost funds:
• remain permanently locked
• reduce effective circulating liquidity
• create persistent “dead supply”
This proposal aims to:
• reintroduce lost or dormant liquidity into the ecosystem
• strengthen network incentives for validators and delegators
• fund long-term protocol development sustainably
• improve capital efficiency without increasing total supply
Core Mechanism
All user-initiated on-chain transactions are treated as valid indicators of wallet control and reset the inactivity timer.
This includes:
• transfers
• staking actions
• governance interactions
• claim transactions
A claim transaction is explicitly defined as proof of wallet control, demonstrating that the private key remains actively accessible by the user. It is treated as a standard on-chain action and is equivalent for inactivity tracking purposes.
Each account tracks:
mapping(address => uint256) public lastActivity;
The inactivity timer is updated whenever a valid on-chain transaction is performed.
Only on-chain verifiable actions are considered valid activity.
If:
Then:
• the wallet is classified as inactive
• the balance is moved to a protocol-controlled escrow state
3. Sweep Logic
Funds accumulated in the treasury are distributed per epoch with caps.
Proposed allocation:
• 45% Validators
• 25% Delegators (Nominators)
• 30% Development Fund (governance-defined allocation)
Treasury Safety Constraints
To avoid centralization and governance abuse:
• Maximum allocation per category per epoch (hard cap)
• Time-locked governance execution (delay before fund movement)
• No single proposal may exceed predefined treasury limits
Developer Governance System
A decentralized governance system determines:
• developer grant recipients
• funding priorities
• ecosystem roadmap decisions
Governance model includes:
• token-weighted voting
• proposal-based funding rounds
• time-locked execution for security
Economic Flow
User activity updates lastActivity
Inactivity threshold is reached
Wallet is marked inactive
Funds move to escrow
Treasury receives funds
Treasury redistributes via staking rewards, delegation rewards, and development grants
Expected Effects
Positive:
• reduction of dead supply
• increased effective liquidity
• sustainable protocol funding
• stronger validator and delegator incentives
Risks:
• perception of ownership loss
• governance capture risk
• inactivity classification edge cases
• regulatory sensitivity
Governance risk mitigation
To reduce political dependency and behavioral distortion in developer funding, the system incorporates the following design principles:
• Governance defines funding rules and budget envelopes, not individual recipients
• A portion of developer funding is distributed via algorithmic, usage-based metrics rather than direct voting
• Rewards are delayed and milestone-based to prevent short-term optimization
• Evaluation uses multiple signals (e.g. commits, usage, audits, adoption) to avoid single-metric gaming
• Funding is partially reputation-weighted instead of punitive, focusing on future eligibility rather than direct penalties
• Governance acts as a policy layer, while allocation is partially automated to reduce centralization risk
Threat Model
Inactivity gaming attempts (minimal transactions to reset timer)
Governance capture risk (treasury control concentration)
Market shock risk from large treasury redistributions
Design Considerations
To ensure fairness and clarity:
• inactivity is strictly defined by on-chain activity
• claim is treated as a normal transaction
• UI warnings must precede inactivity threshold
• governance execution must include delays and caps
• treasury distribution is strictly bounded
Key Idea
Idle capital is not destroyed, but reclassified as lost and gradually reintegrated into the ecosystem under transparent, rule-based governance.
Ecosystem Funding Flow
The protocol redistributes value generated by active usage into ecosystem maintenance and development.
Each epoch, protocol revenue is allocated between validators, existing infrastructure, and a development fund that supports ongoing and new project creation.
Funding allocation is based on a combination of on-chain usage metrics and protocol-defined rules, ensuring that successful and actively used projects naturally receive greater support over time.
This creates a self-sustaining feedback loop where ecosystem usage directly contributes to continued development and long-term growth.
Summary
The system aligns incentives so that value generated within the ecosystem is continuously reinvested into maintaining and expanding it, without requiring manual allocation decisions for each individual project.
Optional Extensions
Treasury Buffer System
• smooths reward distribution
• reduces volatility
• stabilizes staking incentives
Emission Floor
• ensures minimum validator rewards
• maintains network security
Adaptive Emission
Emission adjusts based on:
• staking ratio
• network participation
• treasury balance health
Conclusion
This model transforms inactivity from a passive accounting state into a structured economic recovery mechanism, reinforcing:
• network security
• sustainable development funding
• staking incentive stability
• long-term protocol resilience
Incentive Layer (HODL-friendly extension)
To improve long-term holding incentives without affecting inactivity rules:
• reward multiplier based on holding duration
• applied to staking or treasury distributions
• does not affect inactivity timer
• optional allocation of treasury emissions (10–20%)
• based on snapshot eligibility
• no requirement for active transactions
• minimal interaction to confirm continued ownership
• does not interfere with inactivity logic
Final Summary
This hybrid model improves capital efficiency by reclaiming truly lost assets while preserving incentives for both active participants and long-term holders, resulting in a more resilient and balanced token economy.