SDGP-71: Whitelist 3.Finance - sdCRV TWAVP

Governance Proposals (SDGP)
1

Summary

This proposal requests whitelisting 3.finance from the TWAVP delay to immediately unlock boosted rewards for our permanently locked SDT positions, integrating a protocol that already enforces anti-mercenary temporal friction internally via a rolling 7-day reward distribution. This exemption removes artificial latency for structurally aligned capital, ensuring our permanent SDT commitments immediately secure their full reward-boosting capacity without compromising Stake DAO’s long-term incentive design.

Context

3.finance operates as a sovereign currency protocol engineered to issue GUILD—a stable, unencumbered currency backed by earned protocol equity (held in our Protocol-Controlled Vault) rather than redeemable debt. Our economic architecture maintains a strict separation of assets: our Treasury (The Grove) strategically acquires yield-generating derivatives like sdCRV to generate protocol revenue, while our SDT positions serve a distinct, highly aligned purpose. We systematically acquire and lock SDT specifically to secure Stake DAO’s boosted reward allocations for our depositors.

Rather than fragmenting our focus by actively managing gauge votes, 3.finance delegates its voting power directly to the Stake DAO core team. This delegation is a deliberate operational choice that allows us to focus our resources on expanding our own sovereign economic architecture, while ensuring our SDT and sdToken capital remains under the governance of those most dedicated to Stake DAO’s long-term success. For the Stake DAO community, 3.finance functions as a structural liquidity aggregator that provides locked capital and unwavering, unified governance support.

Rationale

The TWAVP mechanism is an essential anti-manipulation safeguard designed to filter out transient, mercenary capital attempting to flash-stake for short-term reward extraction and governance disruption. 3.finance’s capital architecture is fundamentally incompatible with this type of extraction, and we have engineered our own internal mechanisms to enforce this alignment.

To mitigate mercenary behaviour among our own depositors, 3.finance implements a rolling 7-day reward stream. Every time Stake DAO rewards are processed and allocated to our users, they are locked into a 7-day distribution window; if additional rewards are processed during that period, they are added to the pot and the 7-day distribution timer is reset. This imposes the exact same temporal friction on our users that TWAVP imposes on protocols.

Furthermore, just as our internal reward stream neutralises economic mercenary behaviour, our governance posture structurally reinforces Stake DAO’s cohesion. By delegating our voting power to the Stake DAO core team, we eliminate the risk of fragmented or adversarial governance influence. Mentioning this delegation clarifies our integration model: we are not seeking to bypass TWAVP to exert independent political pressure on gauge allocations, but rather to immediately unlock the economic yield of our permanent capital. Whitelisting 3.finance integrates a protocol that has engineered similar temporal friction internally, while consolidating its governance influence to actively support the core team’s established roadmap, ensuring our economic integration is purely additive to Stake DAO’s stability.

1 Like
2

Vote

For (Yes):
Approve the whitelisting of 3.finance’s integration address from the TWAVP ramp, granting its permanent positions full effective voting power and boost immediately, as described.

Against (No): Reject the proposal.
Abstain: Take no position.

Column 1 Column 2
Parameter Value
Forum debate period 3 days minimum
Voting period 7 days
Debate and vote Sequential (debate first, then vote)
Quorum 15% of total vlSDT supply
Approval threshold Simple majority (>50% of votes cast, excl. abstentions)
Anticipated execution If super-quorum is reached

Address for TWAVP whitelisting: 0xD7Ba3691750153f94dc0EB40bE09448F52f33b13

3

Those wishing to vote on this proposal may do so at:
https://snapshot.org/#/s:stakedao.eth/proposal/0xeec9d5380fb450c82a3f09844e109e948b361ee2dd5de8dd549372dd49cd59c4

4

no reason not to support it, missing 0.9m votes for quorum to be reached, please vote

2 Likes
6

Vote: Against

SDGP-71 does not define what exactly is being exempted: gauge TWAVP, governance TWAVP, boost, or all of them. The title, summary and vote text describe different things.

TWAVP averages the sdCRV-gauge balance. It does not apply to SDT. A permanent SDT lock imposes no waiting period that an exemption could remove.

The 7-day reward stream does not replace TWAVP. It delays payouts to 3.finance users. TWAVP limits how quickly the address itself gains effective voting power from newly acquired sdCRV-gauge.

The safeguards cited in the proposal are not binding. Delegation can be changed, gauge-staked capital can be withdrawn, and the proxy implementation can be upgraded. None of these events automatically revokes the whitelist.

There is no cap, expiry, review period or revocation trigger. If the assumptions behind the exemption stop being true, nothing removes the whitelist automatically. During that time, any voting power exercised or rewards received cannot be reversed.

For these reasons, we cannot support SDGP-71 as written.

7

“SDGP-71 does not define what exactly is being exempted: gauge TWAVP, governance TWAVP, boost, or all of them. The title, summary and vote text describe different things.”

You raise a fair point on clarity. To be explicit: the exemption requested was intended to apply only to gauge TWAVP – the averaging mechanism that delays how quickly newly deposited sdCRV-gauge positions gain full voting power and reward weight. Governance TWAVP and boost calculations are unaffected to my knowledge.

“TWAVP averages the sdCRV-gauge balance. It does not apply to SDT. A permanent SDT lock imposes no waiting period that an exemption could remove.”

Correct. The exemption request is exclusively for sdCRV-gauge positions held within the 3.finance – not for SDT. The SDT discussion was included to demonstrate our broader commitment to StakeDAO, but you are right that it is not relevant to the TWAVP mechanics.

“The 7-day reward stream does not replace TWAVP. It delays payouts to 3.finance users. TWAVP limits how quickly the address itself gains effective voting power from newly acquired sdCRV-gauge.”

This is an important technical distinction, and I appreciate you raising it. You are correct that the mechanisms are different:

  • TWAVP limits how quickly an address gains voting power from new deposits.

  • Our 7-day drip limits how quickly rewards are paid out to users.

However, the functional purpose of both is the same: to prevent mercenary behaviour where a user flash-deposits, claims rewards, and immediately exits. TWAVP prevents that by delaying the accumulation of voting power. Our 7-day drip prevents that by delaying the distribution of rewards.

Given that 3.finance does not participate in weekly gauge votes (all voting power is delegated to the StakeDAO core team), the TWAVP delay on voting power serves no security purpose for our treasury assets. The 7-day reward drip, on the other hand, actively prevents reward extraction for every depositor who uses our protocol.

So while the mechanisms are technically different, they address the same underlying risk, and we have implemented our own solution at the application layer. The exemption simply removes a redundant delay for assets that are already structurally permanent and where voting-power averaging adds no additional security.

“The safeguards cited in the proposal are not binding. Delegation can be changed, gauge-staked capital can be withdrawn, and the proxy implementation can be upgraded. None of these events automatically revokes the whitelist.”

You are technically correct that these are not automatically enforced by smart contract. However, I would make two observations:

First, gauge-staked capital cannot be withdrawn arbitrarily from the 3.finance treasury. Our acquired sdCRV is permanently retained within the protocol treasury as the core engine of our flywheel strategy. Selling it would mean dismantling the protocol itself, which makes no economic sense for a project in active development with a clear 5-stage roadmap (docs.3.finance/road-map) to immutability.

Second, delegation can be changed, but why would we? To clarify, delegating our voting power to the Stake DAO core team is not an act of ‘abandoning’ governance, it is a strategic choice. Our core engineering focus is entirely on building 3.finance’s sovereign currency architecture, rather than participating in weekly gauge votes. This delegation model is explicitly supported within Stake DAO’s own documentation.

More importantly, our delegation is structural and verifiable. The protocols sdCRV and SDT holdings are permanently locked and cannot be withdrawn at will. This means our ‘governance support’ is not a short-term political statement, but a long-term commitment backed by actual, illiquid collateral. If the community believes this concentration of delegated votes is problematic in the future, we are absolutely open to discussing more granular delegation strategies. However, for now, we believe this is the most efficient and consistent way for us to participate in governance without distracting from our core mission.

Regarding proxy upgrades: yes, during our beta phase (we are currently in Stage 3 of 5), our contracts are upgradeable. This is standard practice for protocols in active development. Our roadmap commits to burning admin keys and making contracts immutable upon completion of Stages 4 and 5, post-audits. We are not hiding this; we are being transparent about where we are in our development lifecycle.

If the community would like, we are open to adding a non-binding commitment that we will notify StakeDAO and voluntarily revoke the whitelist if any of these assumptions materially change.

For community members who may be unfamiliar with the background, I want to add that both I personally and the 3.finance project have been closely connected to Stake DAO since its early days. We have consistently supported Stake DAO by locking SDT and delegating our votes. This is not a transactional or temporary relationship: it is rooted in a shared, long-term belief in a truly decentralised and efficient DeFi ecosystem.

“There is no cap, expiry, review period or revocation trigger. If the assumptions behind the exemption stop being true, nothing removes the whitelist automatically. During that time, any voting power exercised or rewards received cannot be reversed.”

This is a valid governance concern, and I agree that permanent exemptions without review are not ideal for the DAO. We are open to the following commitments:

  • Review period: We agree to a voluntary 12-month review, after which the community can reassess whether the exemption remains appropriate. This may be a rolling review if the community deems it necessary.

  • Revocation trigger: If 3.finance ever materially changes its structure (e.g., stops holding permanent sdCRV positions, or changes our delegation strategy away from the StakeDAO core team), we will proactively notify the DAO and support a vote to revoke the whitelist.

These would be non-binding commitments from our side, but we are willing to make them publicly and clearly, so the community knows our intentions. I would also note that rewards received cannot be reversed, but that is true of every whitelisted address. The DAO grants whitelist status based on trust and alignment.

“For these reasons, we cannot support SDGP-71 as written.”

I respect your position, and I appreciate the detailed reasoning. While the proposal has passed, I wanted to address each of your concerns directly because I believe in rigorous governance and want to build trust with all community members, not just those who voted ‘For’.

I hope this addresses your concerns. I am happy to continue the discussion in Discord or Telegram if you have further technical questions.