Upgrade policy

• The registry is an upgradeable proxy: its address never changes, but the code behind it can.
• Every upgrade must go through a timelock, 7 days between the public announcement on chain and the moment it can run. Anyone can watch for it.
• In the deployed code, the only ways money leaves the registry are a user's refund and a sponsor's withdrawal, each to its own owner. The curator and the upgrader have no function that moves it. A future upgrade could in principle change that, which is exactly what the 7-day delay lets you check.
• In an emergency the curator can halt the registry. A halt stops charging and new money and lets every user leave at once; it cannot take funds.
• Upgrades are planned to be given up for good (a freeze) once the contract has proven itself. The date is not set yet.

The curator cannot upgrade, and the upgrader cannot curate. The curator's powers are about running the marketplace (who is a verified sponsor, when to stop in an emergency); none of them touches deposited money.

Today (closed test): one plain account holds the curator role and also the upgrader roles on the timelock. That is a single point of failure and is acceptable only because this is a test with small caps.

At launch: two separate multi-signature wallets (Safe), one for the curator and one for the upgrader, each needing several signers, with the signer list published here. The deployer account keeps no power.

1. The new code is tested, reviewed against the deployed version and rehearsed, and its storage layout is checked so existing balances cannot be corrupted.
2. The upgrader schedules the upgrade on the timelock. The call is public and the chain records the exact new implementation and the earliest time it can run.
3. For 7 days anyone can read it, and users who disagree can request a refund and leave. The refund path always works (two steps, one day apart).
4. The upgrader executes it, or cancels it if a problem turns up. The registry address, every balance and every subscription are unchanged.

An emergency does not skip the delay for code changes. What the curator can do immediately is halt, so users can exit while a fix waits.

• The curator and upgrader become two separate Safe wallets, and their signers are listed on this page.
• The registry is deployed again with a vanity address and final deposit caps. The closed-test registry is retired and its users refund.
• Source code is verified on the block explorer.
• A freeze date is announced. After the freeze nobody can change the code; a needed change then means a new registry and a migration that users opt into.

The name comes from an idea in the account-abstraction work. In October 2022 Vitalik Buterin wrote that the valuable thing ERC-4337 provides is a "decentralized fee market" for user operations: a place where who pays for a transaction, and at what price, is settled openly instead of by one party.

That is what this project builds for ordinary wallets. Sponsors publish their plans and prices on chain, users choose between them, and a sponsor who is unreliable or too dear loses its subscribers. The mechanism has moved on since then: it now uses EIP-7702 delegation and a delegation framework rather than 4337 user operations, and the registry on this page is where the market's rules and balances live.

To see what is scheduled, open the timelock on the explorer and look for CallScheduled events. Questions or concerns: Support. How your data is handled: Privacy policy.