SIP-0094 — final text, and a week to review it before creation
This post is a follow-up to
SIP-0094 (Parts 1–3): Perimeter Fee Activation and Adoption Fund Transfer.
Sovryns,
TL;DR: The Perimeter Fee contracts are deployed, source-verified and rehearsed against a
fork of live mainnet. The first post left the contract tables blank because the contracts did
not exist yet — they are filled in now. The SIP text is final and frozen, see PR#91. Proposals are
created Tuesday, 1 September; the week until then is for public review. Nothing charges
when these proposals execute.
UPDATE 1 Sep: All three proposals are created and voting is live for ~24 hours — see the announcement below for links. The text below is the review-window post, preserved as published; the document it froze is what the proposals carry.
Final text — every address, action and rollback anchor is here:
SIP-0094.md @ 340148c
sha256 496b69a6761f4e41d5e551f9c9f3962570beaba9e4aeb66613265c97fe09c756
That commit and hash are what the three proposals carry in their on-chain descriptions, so
you can prove the calldata you are voting on and this document describe the same thing —
without trusting anyone’s summary of either, including this one.
Why review now
A proposal’s description is written at creation and is immutable from that moment. A wrong
detail cannot be edited; it can only be fixed by cancelling and re-running the vote. So the
useful time to find problems is this week, while corrections are free.
What has been tested
- 290 automated checks, no failures — including that every module being shipped genuinely
differs from what mainnet runs today, that the modules deliberately left out are
byte-identical to what is already registered, and that the identifiers in the deployed
bytecode are current and not a stale generation. - A full governance rehearsal on a forked mainnet, against the deployed bytecode at the
real addresses: both owner-governor proposals created, voted, queued and executed. All ten
Part 1 actions match the SIP’s table exactly. Ordering is fail-closed — running Part 2
first reverts wholesale and moves nothing. Charging stays off through installation; when
switched on it is exactly 10 bps on the intended surfaces and zero on rollovers and
liquidations. The kill switch works both ways. Part 3 was rehearsed with a positive control. - Not established, so it is not claimed: real voting dynamics, gas on the day, and the
front end — verified separately, and it ships before charging is ever enabled.
All contracts are source-verified on Rootstock Blockscout. Five show as partial matches:
the two standard OpenZeppelin proxies, which the explorer matches from its own database, and
the three modules that link an external library, where the compiler metadata differs by
construction. Structural, not a gap in what has been published.
Nothing charges on execution
The system ships installed and switched off. Executing all three proposals leaves the fee
disabled. Enabling is a separate, later Exchequer action after post-deployment verification,
and is not part of any of these ballots.
Timeline
| Now → 31 August | Public review |
| Before creation | Exchequer completes ownership acceptance |
| Tuesday, 1 September | Proposals created — 24h voting, then a 48h timelock (owner governor) or 24h (admin governor) |
| After execution | Front end ships, then charging is enabled at 10 bps |
What we are asking
Read the final text,
hash it, and check the addresses against the explorer. If something is wrong or overstated,
say so in this thread this week, while it costs nothing to fix.
Thank you for the scrutiny. A proposal that has been genuinely examined before creation is
worth more than one that passes quietly.