# \[IP\] Proposal-spam protection upgrade for vlRSR governance

**URL:** <https://forum.reserve.org/t/ip-proposal-spam-protection-upgrade-for-vlrsr-governance/1661>\
**Category:** Governance & Delegates\
**Created:** [October 7, 2026, 12:44am UTC](https://forum.reserve.org/t/ip-proposal-spam-protection-upgrade-for-vlrsr-governance/1661 "2026-10-07T00:44:36Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![tbrent](https://avatars.discourse-cdn.com/v4/letter/t/bbce88/32.png) [@tbrent](https://forum.reserve.org/u/tbrent)\
**Post date:** [October 7, 2026, 12:44am UTC](https://forum.reserve.org/t/ip-proposal-spam-protection-upgrade-for-vlrsr-governance/1661/1 "2026-10-07T00:44:36Z")

</div>

**Summary**

This RFC proposes upgrading the two vlRSR governance systems associated with Reserve’s five AI DTFs and MAG7 to Reserve Governor 1.1.0:

- **BSC vlRSR:​** [0xE744C8157c346B2931807F42552c8CBc0BB6D34f](https://bscscan.com/address/0xE744C8157c346B2931807F42552c8CBc0BB6D34f), used by BUILDOUT, POWER, NEOCLOUD, PHOTON and ROBOTS.[3][4]
- **Base vlRSR:​** [0x2F0D6538807a77d4AdDCd4b4DAf214Ea2E818E3D](https://basescan.org/address/0x2F0D6538807a77d4AdDCd4b4DAf214Ea2E818E3D).[3][5]

The purpose of the upgrade is proposal-spam protection.[2]

Release 1.1.0 extends the proposal throttle (previously optimistic proposals only) to standard proposals. [1][2]

**How the spam protection works**

Release 1.1.0 uses a shared per-account proposal throttle across both governance paths. Standard and optimistic proposals draw from the same refillable allowance over a 12-hour period, limiting how quickly one account can submit proposals.[1][2]

For standard proposals, the proposer must meet the proposal threshold using both their voting power at the current timestamp and their average voting power over the preceding 12 hours, normalized by average total supply.[1][2]

Together, these checks form one proposal-throttling mechanism: an account cannot rapidly propose too many proposals at once, and voting power acquired or delegated only briefly cannot be used immediately to propose.[2]

For more context on the necessity of this approach, see [the recent flurry of spam proposals levied against BDTF.](https://app.reserve.org/base/index-dtf/0xb8753941196692e322846cfee9c14c97ac81928a/governance)

**Additional upgrade safety**

Release 1.1.0 also adds version-registry checks for the vlRSR vault, governor and timelock. Future upgrades of these components must match the latest registered, non-deprecated governance release. [2]

**Proposed action**

Submit one standard governance proposal to each vlRSR DAO:

1. Upgrade the shared AI DTF vlRSR system on BSC to Reserve Governor 1.1.0.
2. Upgrade the MAG7 vlRSR system on Base to Reserve Governor 1.1.0.

Each proposal will upgrade the staking vault, governor, and timelock. The three upgrades will be batched atomically, with the vault upgraded first, so the system cannot be left partially upgraded.[2]

**Technical execution**

At the lower level, each proposal will execute the following calls in order:

```auto
vault.upgradeToAndCall(vaultImpl, initializeAverageVotes())
governor.upgradeToAndCall(
    governorImpl,
    initializeVersionRegistry(0x0692eCddFe6ad18dBD4BBD7D1ea506e461Eb87aA)
)
timelock.upgradeToAndCall(
    timelockImpl,
    initializeVersionRegistry(0x0692eCddFe6ad18dBD4BBD7D1ea506e461Eb87aA)
)

```

In the final proposal payloads, `vaultImpl`, `governorImpl` and `timelockImpl` will be the implementation addresses registered for release 1.1.0 on that chain, as gotten from the official Deployer contracts: [Release 1.1.0 · reserve-protocol/reserve-governor · GitHub](https://github.com/reserve-protocol/reserve-governor/releases/tag/r1.1.0)

 ![Screenshot 2026-10-06 at 5.38.03 PM](https://europe1.discourse-cdn.com/flex005/uploads/reserve/original/2X/4/46e3240aeb1b0aeeb30754d4cbcaafa2d411dbdc.png)

**What does not change?**

This upgrade does not change:

- the baskets, mandates or fees of BUILDOUT, POWER, NEOCLOUD, PHOTON, ROBOTS or MAG7;
- vlRSR balances or underlying RSR balances;
- existing standard or optimistic delegations;
- reward-token configuration or the unstaking delay;
- the optimistic proposer, veto threshold or selector permissions; or
- proposals in flight, voting periods, quorum settings or timelock delays.

**No token migration or other action is required from vlRSR holders**.

**Risks and considerations**

As with any proxy upgrade, there is implementation and execution risk. The proposals mitigate this by using only the registered 1.1.0 implementations and batching each system’s three component upgrades atomically.[2]

These 1.1.0 implementations, along with the described upgrade path, have been vetted by Trust Security.

After execution, standard-proposal eligibility will ramp up as the 12-hour time-weighted period accrues. This affects the ability to create standard proposals for a short period of time; it does not prevent vlRSR holders from voting or vetoing proposals.[2]

**Feedback requested**

Please share any feedback or objections to applying the Reserve Governor 1.1.0 proposal-spam protection upgrade to both vlRSR governance systems.

If there are no material objections during the RFC period, the next step will be to publish the exact proposal payloads and submit the two standard governance proposals onchain.

_Poll ([view on site](https://forum.reserve.org/t/ip-proposal-spam-protection-upgrade-for-vlrsr-governance/1661/1))_

**Sources**

[1] [Release 1.1.0 · reserve-protocol/reserve-governor · GitHub](https://github.com/reserve-protocol/reserve-governor/releases/tag/r1.1.0) — Reserve Governor 1.1.0 release  
[2] [reserve-governor/README.md at r1.1.0 · reserve-protocol/reserve-governor · GitHub](https://github.com/reserve-protocol/reserve-governor/blob/r1.1.0/README.md) — Reserve Governor 1.1.0 upgrade guide  
[3] [reserve-governor/test/fork/README.md at r1.1.0 · reserve-protocol/reserve-governor · GitHub](https://github.com/reserve-protocol/reserve-governor/blob/r1.1.0/test/fork/README.md) — Reserve Governor 1.1.0 fork-test fixtures  
[4] [https://bscscan.com/address/0xE744C8157c346B2931807F42552c8CBc0BB6D34f](https://bscscan.com/address/0xE744C8157c346B2931807F42552c8CBc0BB6D34f) — Shared AI DTF vlRSR vault on BSC  
[5] [Address: 0x2F0D6538...a2E818E3D | BaseScan](https://basescan.org/address/0x2F0D6538807a77d4AdDCd4b4DAf214Ea2E818E3D) — MAG7 vlRSR vault on Base

---

<div class="post-metadata">

**Author:** ![ham](https://avatars.discourse-cdn.com/v4/letter/h/ecb155/32.png) [@ham](https://forum.reserve.org/u/ham)\
**Post date:** [October 7, 2026, 4:01pm UTC](https://forum.reserve.org/t/ip-proposal-spam-protection-upgrade-for-vlrsr-governance/1661/2 "2026-10-07T16:01:28Z")

</div>

Excellent proposal @tbrent. Appreciate you and the team for promptly addressing and patching this gov attack vector.

Very much in favour of this than some of the other proposed solutions being floated at the time so will vote in favour on both vlRSR systems.

Given the AI DTF vlRSR system sans 5 DTFs could you please just give us a little more information on how the AI DTF System will be updated? How this will be proposed, where we will be able to find the proposal on the front end, if it will be able to be executed in the same way as other proposals etc. Thanks.

---

<div class="post-metadata">

**Author:** ![tbrent](https://avatars.discourse-cdn.com/v4/letter/t/bbce88/32.png) [@tbrent](https://forum.reserve.org/u/tbrent)\
**Post date:** [October 7, 2026, 11:16pm UTC](https://forum.reserve.org/t/ip-proposal-spam-protection-upgrade-for-vlrsr-governance/1661/3 "2026-10-07T23:16:33Z")

</div>

> Given the AI DTF vlRSR system sans 5 DTFs could you please just give us a little more information on how the AI DTF System will be updated? How this will be proposed, where we will be able to find the proposal on the front end, if it will be able to be executed in the same way as other proposals etc. Thanks.

The overall spam-resistant optimistic governance upgrade will have 3 rounds of upgrades, of which this is #1:

1. Upgrade AI DTF + MAG7 **vlRSR** governance systems (this RFC)
2. Upgrade AI DTF + MAG7 **Folio** governance systems (has #1 as prerequisite)
3. Upgrade legacy DTF **Folio** governance systems (has #1 as prerequisite)

**StakingVaults have to be upgraded before Folios** because the new governance system depends on the StakingVault they are tied to supporting time-weighted-stake. Hence: #2 and #3 must WAIT until #1 resolves.

Legacy DTFs that use RSR for governance will be tied into the new singleton vlRSRs currently in use with the AI DTFs + MAG7. So: 1 StakingVault per chain (for RSR).

Note: singleton vlRSRs pay their yield in RSR. Revenue from all DTFs is automatically converted into RSR which automatically accrues to vlRSR holders via an appreciating exchange rate.

* * *

The technical onchain proposal for each of 1-3 are as follows:

1

```auto
vault.upgradeToAndCall(vaultImpl, initializeAverageVotes())
governor.upgradeToAndCall(
    governorImpl,
    initializeVersionRegistry(0x0692eCddFe6ad18dBD4BBD7D1ea506e461Eb87aA)
)
timelock.upgradeToAndCall(
    timelockImpl,
    initializeVersionRegistry(0x0692eCddFe6ad18dBD4BBD7D1ea506e461Eb87aA)
)

```

2

```auto
folioGovernor.upgradeToAndCall(governorImpl, initializeVersionRegistry(0x0692eCddFe6ad18dBD4BBD7D1ea506e461Eb87aA))
folioTimelock.upgradeToAndCall(timelockImpl, initializeVersionRegistry(0x0692eCddFe6ad18dBD4BBD7D1ea506e461Eb87aA))

```

3

```auto
GovernanceSpell_09_18_2026.upgradeFolio()

```

with spell addresses:

```auto
- Mainnet: https://etherscan.io/address/0x11B1bF67F0c6495E1F2d34cDe0296A02C2540926
- Base: https://basescan.org/address/0x5771d976696AA180Fed276FB6571fE2f41D0b849
- BSC: https://bscscan.com/address/0x60C384e226b120d93f3e0F4C502957b2B9C32B15

```

Each of these proposals will be proposed by the ABC Labs team, though anyone could propose them.

* * *

The frontend should be pretty straightforward: once proposed, each proposal will under the /governance tab for the associated DTF.

In the **vlRSR** case for the AI DTFs, the same proposal will show up under _all_ DTFs. E.g if you vote on the proposal from PHOTON’s governance page, you will not need to (or be able to) vote again from BUILDOUT’s governance page.

* * *

Lastly, OPEN and ABX require some special handling since their vl-tokens are not RSR. More to come on this front.

---

<div class="post-metadata">

**Author:** ![Raphael\_Anode](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.reserve.org/raphael_anode/32/1100_2.png) [@Raphael\_Anode](https://forum.reserve.org/u/Raphael_Anode)\
**Post date:** [October 9, 2026, 8:17am UTC](https://forum.reserve.org/t/ip-proposal-spam-protection-upgrade-for-vlrsr-governance/1661/4 "2026-10-09T08:17:40Z")

</div>

Very good proposal and a great way to prevent someone from submitting 1,627 spam proposals in a night.

Full support.

---

<div class="post-metadata">

**Author:** ![tbrent](https://avatars.discourse-cdn.com/v4/letter/t/bbce88/32.png) [@tbrent](https://forum.reserve.org/u/tbrent)\
**Post date:** [October 27, 2026, 1:41am UTC](https://forum.reserve.org/t/ip-proposal-spam-protection-upgrade-for-vlrsr-governance/1661/5 "2026-10-27T01:41:06Z")

</div>

This has been promoted to IP.

Proposals are live, voting will be Wed October 28th - Fri Oct 30th

- bsc : [Reserve app | DTFs](https://app.reserve.org/bsc/index-dtf/0xd7ce7a841310982acd976d1a6fe7bb6063c5689d/governance/proposal/99923920669475833231830320102798982296541580436560436701789787622876221308962)
- base: [Reserve app | DTFs](https://app.reserve.org/base/index-dtf/0xcef8db49e456f872e288e1c042f916e9ced7c781/governance/proposal/34983877613328503414578261601915135387792862274647119927804327391297648966929)
- mainnet: [Reserve app | DTFs](https://app.reserve.org/ethereum/index-dtf/0x09a823930fab5b1fda6e519b1ee33e7da9bda0e5/governance/proposal/69201359959832642973889874770712919966633171488051517505829502689914136007106)

---

<div class="post-metadata">

**Author:** ![sagix.io](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.reserve.org/sagix.io/32/1001_2.png) [@sagix.io](https://forum.reserve.org/u/sagix.io)\
**Post date:** [October 27, 2026, 7:40pm UTC](https://forum.reserve.org/t/ip-proposal-spam-protection-upgrade-for-vlrsr-governance/1661/6 "2026-10-27T19:40:35Z")

</div>

hey Taylor @tbrent

Support this IP. One request for legacy DTFs: **a 3-month lock-up period to propose** , not 12 hours.

ixEDEL is under attack right now. ixEdel is not a legacy DTF, is an active one.

A fresh wallet funded, bought RSR, locked and proposed a malicious `startRebalance` in 9 minutes. The 12-hour window would catch that. But the same actor’s main wallet had held stake for days and has already passed proposals on BRAZIL71, Neo Tokyo Gaming, Cross-chain Index and an RToken. 12 hours stops spam, not patient capture.

A 3-month lock-up forces an attacker to commit capital and sit visibly on-chain for a quarter before he can propose. Small DTFs with few holders need that. Guardians could be exempt so rebalances aren’t blocked.

I have a full incident report for the team if useful.