How the press changes hands

01Overview#

AFTERDEV keeps a Solana project running when its operator changes. A project registers, with its current operator's consent, an official page, a redeployable source package, an operator role and a USDC operating vault. When the rules the project agreed to in advance are met (a vote by deposited project tokens, a challenge window and a timelock), one transaction hands the operator role and the vault's spending right to the next operator. The CA, the vault address and the whole record stay the same.

02How a handover works#

1. NOTICE
2. VOTING
3. CHALLENGE
4. TIMELOCK
5. EXECUTABLE
6. EXECUTED

A proposal that misses quorum or approval ends REJECTED. A reviewer veto, a withdrawal, a stale base (the operator or policy changed meanwhile) or an unused execution window ends it CANCELLED. Every deadline is stored on the proposal when it is created; the state follows the chain clock.

1. Register

   The current operator registers the CA, the official page, the package hash and license, the policy, the USDC vault with its recipients and limits, and the reviewer multisig. Consent is checked on chain: the registering wallet is the mint authority, or the AFTERDEV attestor co-signs after confirming the creator. One CA can be registered once.

2. Propose

   The operator, or a holder with a matured vote deposit, proposes the next operator. If the policy sets an inactivity condition, a holder can propose only after the operator has been silent that long; the operator can hand over voluntarily at any time. The proposal copies the policy's windows, quorum, approval and reviewer list, and a notice window opens.

   Find the project in the console

3. Vote

   Holders vote yes or no with project tokens that were in the vote escrow before the proposal's snapshot. When voting ends the tally is fixed: below quorum or approval, the proposal is rejected.

   Vote in the console

4. Challenge

   Anyone can file a challenge with a reason from the notice window through the challenge window. The project's reviewer multisig can cancel the proposal during the challenge window; it cannot do anything else.

   File a challenge in the console

5. Timelock

   A passed proposal waits out the timelock. Nothing changes hands yet, so everyone has time to see what is about to happen.

   Watch the run in the console

6. Execute

   Once the proposal is executable, anyone can execute it. One instruction sets the new operator, raises the operator epoch and writes the history record, so the vault's spending right moves with it. A second execute fails. If nobody executes before the execution window closes, the proposal is cancelled as expired. After any ending, voters release their locked votes.

   Check it in Receipts

03What transfers and what does not#

04Voting rules#

• Vote token. Handover votes use the project's own token (its CA) deposited in that project's vote escrow.
• Snapshot. Only deposits older than the policy's minimum deposit age when the proposal is created count. A deposit made later, or a deposit topped up later, has to mature again. Tokens moved to another wallet and deposited again start a new age.
• Quorum and approval. Votes cast must reach the quorum share of the eligible deposits, and yes votes must reach the approval share of the votes cast. Each proposal keeps the values it copied at creation; the console shows them.
• Locked until the end. A vote locks the deposit until the proposal is executed, rejected or cancelled. Then the voter releases the lock and can withdraw.
• One vote per wallet per proposal. A second vote on the same proposal fails, and a locked deposit cannot be withdrawn to vote again elsewhere. The same deposit may vote on two different proposals that are open at once.
• No delegation. Each wallet votes its own deposit.
• Token weight is not head count. The tally is locked token weight. A wallet with a large deposit outweighs many small ones, and the screens never show it as a number of people.

05Challenges and the reviewer#

• Anyone can file a challenge with a reason, from the notice window through the challenge window.
• The reviewer multisig is named at registration. Each proposal copies the reviewer list and threshold when it is created, so a later change does not reach a running proposal.
• Cancel only. During the challenge window, with at least one challenge filed, the reviewers can cancel the proposal by reaching the threshold on the same reason. They sign no instruction that moves tokens or USDC, pays out, or changes the operator.
• Decision deadline. The end of the challenge window. Without a cancel by then, the proposal moves on to the timelock.
• The decision (reason hash, which reviewers approved, time) is written to the proposal account and its events.
• Replacing the reviewer is itself a policy proposal.

06Vault rules#

• Each allowed asset has its own vault token account, owned by the project account. Anyone can deposit.
• Pre-registered recipients. A payout is signed by the current operator and goes only to a recipient and purpose listed in the active policy.
• Epoch caps. Each recipient and each asset has a spending cap per epoch. A payout over the cap is refused.
• One request, one payout. Every payout carries a request id and leaves a receipt account; the same request id is refused the second time.
• No instruction empties the vault, and no admin key withdraws from it.
• Changing recipients or limits is a policy proposal with the full notice, vote, challenge and timelock. The new policy applies after it is executed; running proposals keep the rules they started with.
• Vault money belongs to the project. It is never AFTERDEV revenue.

07Official page permissions#

• The official page is served at /p/your-slug. Its footer shows the current operator, the epoch and the revision hash.
• Only the current chain operator edits. At every save the server reads the project account at finalized commitment and compares the signed-in wallet with the operator on it. Another wallet gets "Only the current operator can edit this page."
• Old sessions end at a handover. A session is tied to the operator epoch it signed in under. After a handover it is refused with "Operator changed. Sign in again."
• Every revision keeps its content hash, author and operator epoch. Saving over a newer revision asks you to reload it first.
• A failed deploy is retried, not lost. The revision is saved first and its deploy is recorded on its own, so the current operator can retry it. A handover never waits for a page deploy.

08Costs#

• Pilot projects run by the team pay nothing. Provided by the AFTERDEV team
• Solana network fees are paid by whoever signs the transaction.
• Not revenue, ever: vault money, donations, vote escrow deposits, deposited $AFTER, and an execution fee before its handover is executed. These sit in their own accounts and no settlement reads them.
• Prices are versioned. A new price applies to new payments only.

09$AFTER#

Buy and burn, from two sources

• Creator fees. 25% of every $AFTER creator fee claim is set aside to buy $AFTER.
• Service net revenue. 20% of each settlement's service net revenue is set aside to buy $AFTER.
• Each buy is a market transaction from the AFTERDEV wallet, tagged with its source, and is followed by a separate SPL burn transaction for the whole amount. A buy counts as burned once its burn is finalized and the mint supply fell by exactly that amount; until then it shows as held for burn. Every buy and burn is listed in Receipts with its Solscan transaction.

Service net revenue and how it is split

Service net revenue = recognized registration, hosting and execution fees, minus third-party costs, operating costs and refunds, minus a 10% reserve while the reserve is under 300 USDC. It is settled every 15 minutes and split:

Pilot Ballot

The team gives three free pilot seats per round to applicant projects (registration fee and three months of hosting waived, 100 USDC placed in the project's vault). $AFTER holders choose them with a free signature; a wallet's weight is its lowest $AFTER balance across the round's snapshots, and the full result is published for anyone to recompute.

Risk: $AFTER can fall in price. Each distribution is the share of service net revenue recognized in that settlement window, so one window's amount does not set the next.

10Network and contracts#

The status chip in the bar at the bottom of every app screen comes from GET /api/status. The screens never guess it.

PREVIEW

Programs not deployed on the current network, or the chain could not be read. The reason shows next to the chip.

LIVE

The site is open and the programs answer on the current network. Every record on the screens comes from that network.

Program IDs on the current network, with their Solscan accounts:

11API#

Every route is on this site under /api. Reads need no key and no sign-in. Responses are never cached.

{ "ok": true,  "data": { ..., "meta": { "network", "source", "isTest", "indexedSlot", "asOf" } } }
{ "ok": false, "error": { "code": "NOT_OPERATOR", "message": "Only the current operator can edit this page." } }

• Decide on error.code; error.message is a sentence you can show as is.
• Token amounts are integer strings in base units with their decimals. Times are ISO strings; chain times are unix seconds in fields ending in Ts.
• Addresses are full base58. explorerUrl is a Solscan link built by the server (null when no public explorer covers the chain).
• meta.source says where a block came from: chain (read at finalized commitment for that request) or indexer.

Transaction builders (POST) return an unsigned transaction for the wallet to sign; send an Idempotency-Key header with each. After signing, POST /api/tx/confirm reports indexed, pending or failed.

12Risks#

• Governance capture. Votes are weighted by tokens, not people. A large holder with a matured deposit can pass a handover through the normal process; the notice and challenge windows and the reviewer's cancel are the buffers.
• Reviewer dependence. A captured reviewer can cancel a fair proposal, and an absent reviewer cannot stop a bad one.
• Attestor trust. For a CA without a mint authority (Pump.fun tokens, for example), consent at registration rests on the AFTERDEV attestor's check of the creator.
• Upgradeable programs. The programs can be upgraded by their upgrade authority, a key held by the AFTERDEV team.
• No external audit. The programs have not had an external security audit.
• Outside AFTERDEV. X accounts, domains, copyright, liquidity and creator fees stay with the people who hold them until they move them. USDC can be frozen by its issuer. Vote tokens with a transfer fee are outside what the vote escrow supports.
• Legal review. Deposits that share service revenue may be treated differently by law in different places, and AFTERDEV has not reviewed every jurisdiction. Check the rules where you live before depositing.
• Price. $AFTER can fall in price.