Upgrade authority policy

Not yet reviewed by a lawyer. This document is published in draft so you can read it before you commit money, not because it is finished. No operating company has been formed and no governing law has been set, so parts of it name gaps rather than answers. It will be reissued once counsel has been through it. Questions: info@decentralprop.com

1. Why this document exists

A Solana program can be replaced by whoever holds its upgrade authority. The replacement takes effect immediately, needs nobody's consent, and can do anything the program could do, including moving every lamport the program controls.

For DecentralProp that means the upgrade authority sits above every other protection described anywhere else in this documentation. Two-key rules on payouts, destination-bound settlement, the fraud-proof window: a malicious upgrade removes all of them in one transaction. Any honest description of what a trader is trusting has to start here.

So this page states who holds that authority now, who will hold it, what would still be possible even after the strongest step available, and how to verify each claim yourself.

2. The five programs

Addresses are the program-keypair public keys and are the same on every cluster. firm, challenge and dispute are the settlement-critical set: they hold or move value. batch and bonding_curve are peripheral in the sense that failure there stalls the protocol rather than draining it.

3. Where this stands today

One key controls all five programs. It is a single hot keypair, not a multisig and not hardware-backed. Whoever holds it can replace any program at any time with no delay and no notice.

That is the honest current state and it is the single largest risk in the protocol. It is stated the same way in the risk disclosure, and it is not something a reader should have to infer.

The hardware for the first step was ordered on 2026-08-18. Until it arrives and the multisig is created, nothing in section 4 has happened yet.

4. Where it goes, and what triggers each step

Deliberately, these commitments are tied to events anyone can observe rather than to dates. A date this project misses is worse than no date at all, and calendar promises on unfunded work are how trust documents become fiction.

Step 1: multisig, before the first mainnet firm deploys

Upgrade authority for all five programs moves to a Squads v4 multisig requiring 2 of 3 signatures.

The three signers are a founder key, an independent co-founder or advisor who generates their own seed on their own device, and a joint cold backup that neither party can reach alone. The arrangement is chosen so that no single person, the founder included, can reach the threshold by themselves. All three are Ledger Nano S Plus hardware wallets bought direct from the manufacturer.

The transfer mechanism has already been proven end to end on devnet against a throwaway program: create the multisig, move the authority, approve 2 of 3, upgrade. That was a rehearsal, not the migration.

Step 2: timelock, after an independent audit

The multisig ships with no timelock, and that is a deliberate choice rather than an omission.

The programs have not had an independent third-party audit. That is disclosed in full on the security and audit status page. While that remains true, a long timelock makes things worse rather than better: it publishes a countdown telling anyone watching that a fix is coming and roughly what it touches, and for the same period it prevents the fix from landing. On an unaudited protocol the ability to patch quickly is worth more than the ability to promise you cannot.

Once an audit has been completed and the findings closed, that trade flips. A timelock is added then, and its duration is published here before it is applied.

Step 3: revoke, on the settlement-critical programs

After an audit and a meaningful period of real usage without a bug requiring an upgrade, upgrade authority on firm, challenge and dispute is set to --final. This is irreversible. Those programs can never be changed again by anyone, including the signers.

batch and bonding_curve are expected to stay upgradeable behind the step-2 timelock, because both are areas where a compatibility fix may still be needed and neither can be used to move trader funds.

5. What a revoke would not stop

This is the part such a document usually leaves out, and leaving it out would make everything above misleading.

The firm program has a configuration authority stored in its own state, separate from the upgrade authority. It gates a single instruction that can repoint where certain protocol fee legs are paid and can repoint the platform guardian address that newly deployed firms are bound to. That instruction checks the stored field, not the upgrade authority, so it keeps working after upgrade authority is revoked.

Concretely: after step 3, nobody could change the rules of settlement, but the holder of that configuration authority could still redirect protocol fee revenue, and could change which guardian key gets bound into firms deployed after the change. It does not reach into firms already deployed, whose guardian is copied at deploy time, and it cannot redirect a trader payout, because every payout leg is bound on-chain to the recorded trader's address and no configuration field can alter that.

Closing this is tracked work. The two candidate fixes are binding those destinations to program-derived addresses that no key controls, or putting the lever behind the same timelock and revocation as everything else. Until one of them ships, "upgrade authority revoked" would not mean the protocol is fully immutable, and this document will not claim it does.

6. How to verify any of this

None of the above requires trusting the page. For each address in section 2:

solana program show <PROGRAM_ID> --url mainnet-beta

The Authority field is the current upgrade authority. If it reads none, that program has been made final and can never be upgraded again. If it reads an address, check whether that address is a Squads multisig account rather than an ordinary wallet, and read its threshold and signer set, which are public on-chain.

Program upgrades are transactions like any other. Every upgrade that has ever happened is in the transaction history of the program's data account, with a timestamp and a signer, and no amount of documentation can hide or alter that record.

7. When this page changes

Each step above is reflected here in the same change that executes it, not afterward. If this page says a step has not happened, it has not happened.

Questions: info@decentralprop.com