Controls and risks
Who can change what?
| Authority | Current capability |
|---|---|
| Token creator | Chooses launch metadata and the graduation approval flag; has no setter for either after launch. |
| Mint authority | Removed after the initial supply is minted; no further minting through that authority. |
| Freeze authority | Absent on newly created mints. |
| Platform signer | Co-signs restricted buys and launches; can claim accrued platform fees. |
| Program upgrade authority | Can replace program code while that authority remains configured. |
Have the programs been audited?
The current programs are unaudited. Tests and transaction simulations exercise expected behavior and selected failure cases, but do not establish that all vulnerabilities have been found. Mainnet deployment does not change that status.
A token listing, platform signature, or fixed mint supply does not certify a creator or guarantee a token’s value. Developer tokens have no built-in vesting, and concentrated holders can sell.
What if the platform goes offline?
New launches and restricted buys need the approval service. A compatible client can still submit sells, or open graduated buys, directly to the market program without that service. This requires access to Solana RPC and a client that supports the program.
Website availability, approval availability, RPC history, and IPFS hosting are separate dependencies. A disconnected live-data feed does not cancel a transaction already submitted to Solana.
What are the current operational limits?
The transaction journal uses a persistent file store and serialized writes in one app process. Upload drafts and streaming subscriptions are process-local. The deployment is designed for one app replica; adding replicas requires shared transaction coordination.
The current app does not provide an independently audited liquidity lock, a permanent historical indexer, or universal wallet and aggregator compatibility. Use the specific market’s on-chain state and signed transaction when assessing a trade.