Summary:
This proposal suggests the integration of whitelisted locked Frax-related assets (e.g., cvxFXS, sdFXS) into the node setup process currently under development. The objective is to improve the peg and long-term alignment of incentives by allowing only safe, vested assets to be used in node creation, with a mechanism to slash and burn these assets (and their associated FRAX) in the event of misbehavior. This should be automated via smart contracts to ensure transparency and efficiency.
Motivation
Frax is currently developing its node infrastructure. This presents a critical opportunity to architect economic security and peg stability from the ground up. Locked assets such as cvxFXS and sdFXS represent long-term, committed capital. By leveraging them in node creation, Frax can:
- Increase peg resilience through the use of illiquid, long-term-aligned capital.
- Create a new utility for locked FRAX assets, thereby increasing demand and locking more supply.
- Generate income by collecting the veFRAX revenue for those locked assets slashed in the node until they are unlocked.
Specification
- Node Setup with Locked Assets:
Node operators must deposit only locked assets such as cvxFXS, sdFXS, or even natively locked veFRAX when registering a node, in addition to FRAX. - Slashing Mechanism:
If a node is slashed due to malicious behavior or protocol violation:
• The locked asset is burned.
• An equivalent amount of FRAX tied to the locked derivative is also burned once it has vested, reducing circulating supply. - Redirected Interest (Convex Case):
In the case of Convex-derived assets (e.g., cvxFXS, sdFXS), the 4-year vesting interest could be diverted to buy FRAX on the open market.
This bought FRAX could:
• Be added to the protocol treasury.
• Be used for veFXS bribes.
• Be redistributed to good-standing node operators as additional incentives. - Transparency via Smart Contracts:
• All deposits, slashes, burns, and interest redirections should be automated and visible on-chain.
• Manual overrides should only be possible via governance agreement with both protocols (e.g., convex and Frax Finance).
Why Now?
Frax is actively building its node infrastructure. Introducing this mechanism now allows it to be properly integrated into the core logic, tested, and audited as part of the current development cycle. Retroactively adding such economic security would be significantly more complex post-launch and could lead to misaligned incentives.
Conclusion
This proposal strengthens the peg, increases locked FRAX utility, and aligns node incentives with long-term protocol health. With node infrastructure still in development, now is the best time to build this functionality in.