[TEMP CHECK] Integrating Locked Assets into Node Setup to Strengthen Peg and Incentive Alignment

General Discussion
1

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.

2
  1. Doesn’t this mean frax locked with a liquid locker could be used twice for validation? The liquid locker has veFrax they can use for a node, and then the lqiuid locker token backed by that same veFrax could be used for another node.
  2. This delayed burn feels like it leave area for exploit. The token that’s burned isn’t really a frax token. How would this process interact with those wrapper protocols?
  3. Does this mean if a user stakes a liquid locker token, the veFrax revenue backing that wrapper token would go to Frax instead of the veFrax holder (I.e., the protocol that controls the wrapper)?

I’m not opposed to ideas like this, but I have some concerns about this implementation.

3

Thanks for raising the questions. You have raised good points:

  1. I agree with your point it should only be possible with cvxfxs not with locked veFrax. I’m of the idea that locked veFrax should have same advantages as liquid lockers, but it may be that there is no option for veFrax.
  2. Convex and other protocols should develop a smart contract in case they want to gain access to staking. These smart contract should have the capacity to burn cvxfxs for example, and get frax in 4 years time back.
  3. This is only for the tokens that have been slashed that you get the revenue for the time that they are being unlocked.
4

Why can’t the node setup process be limited to (locked) frax and the liquid wrapper protocols forward benefits to holders of thr wrapper token? It feels much cleaner and simplier, keeps frax controlled assets as thr security mechanism, and net should provide thr same benefits/revenue to holders as if they staked thr wrapper. It’s also ho thr protocols have worked in the past; protocols get thr benefit and forward.

1 Like
5

You are spot on, it makes more sense to have it just for the locked Frax. Hybrid approach complicates things.
I wonder what the team thinks about this?