> For the complete documentation index, see [llms.txt](https://docs.trucee.fun/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.trucee.fun/roadmap.md). # Roadmap Everything on this page except the [Shipped](#shipped) section is **not shipped**. These are features in progress, ideas we have researched, and ideas we cut from the hackathon build. For what Trucee does today, see [How it works](/how-it-works.md) and [Security](/security.md). {% hint style="info" %} Apart from the Shipped section, nothing below is live on any network. A roadmap item has no guarantee of shipping, and its design can change. {% endhint %} ## Shipped Router v5 is the router on devnet, deployed on 2026-10-11 in slot 509900704. It is also the build pinned for mainnet: source pinned at `3985d1f`, sha256 published (see [Security → Upgrade authority](/security.md#upgrade-authority)). Its on-chain features: * **Core:** cost basis per position, exit at cost from a per-market buffer, the surplus split at graduation, and the transfer hook that keeps every pre-graduation trade inside the router. * **Auto-Exit:** set a deadline, and if the curve has not graduated by then, anyone can exit your whole position at cost for you. * **Anti-Whale cap:** no buy may leave one position above 20% of the curve's sale supply. * **Native Referral:** a buy may name a referrer (see below). * **Preset checks:** `init_market` opens a market only for a config with no creator allocation, dynamic supply, permanently locked liquidity, DAMM v2 migration with no migration fee, and an immutable token authority. [How it works](/how-it-works.md) describes each of them. ### Native Referral Without a referrer, the router passes an empty placeholder as the referral account when it calls Meteora DBC's `swap2_with_transfer_hook`. With Native Referral, a buy can pass a referrer's quote token account instead, so the referrer earns a cut of the trading fee on the trades they refer. In the web app, a token page link with `?ref=` names that wallet as the referrer (see [For traders → Referral links](/for-traders.md#referral-links)). DBC pays the referral cut out of the **protocol** fee (20% of the protocol share). The buyer's cost and the exit-at-cost refund do not change. Details: [Programs reference](/programs-reference.md). ## In progress The hackathon's on-chain scope is router v5 above. Retention Fee, the last router feature in that scope, was cut before the scope freeze (2026-10-12 12:00 UTC); see [Research](#research). What is still in progress is off-chain: * **Devnet hosting.** The web app and the crank are being set up on AWS for a public devnet demo. Nothing is publicly hosted yet; today they run locally against devnet. * **A verifiable mainnet build.** A `solana-verify` build of both programs, so anyone can check the deployed bytes against the source. It is blocked until the owner's build machine is ready. Until then the mainnet release is described as source pinned at `3985d1f`, sha256 published. * **Mainnet deploy.** The owner deploys the hook and router v5 to mainnet with the same program IDs as devnet. Neither program is on mainnet yet. ## Planned features ### Zero-Loss Exit Today an exit before graduation refunds your cost basis minus the trading fee and a small rounding haircut. Zero-Loss Exit would use the partner's share of trading fees to pay back the exit fee, so the most you lose on an exit is roughly the protocol's share of the fee. It would draw on the same fee pot as Retention Fee (see [Research](#research)), so the two cannot both ship. ### Wallet-Native Basis Today Trucee tokens cannot be sent between wallets before graduation: the transfer hook only allows transfers that go through the Trucee router. Wallet-Native Basis would let the hook move your cost basis along with your tokens on a plain wallet transfer. Our research (2026-10-06) found it technically feasible, with open problems: * **Basis stripping.** Rounding when basis moves with a transfer could leave the refund buffer insolvent. The fix is to round against both sides and burn the remainder. * **Trustless OTC.** A seller and buyer could settle an off-curve sale atomically (a Jito bundle with an assertion program). This cannot be blocked on-chain, and it applies to **any** pre-graduation transfer design, including a transfer-with-basis instruction in the router. * **Auto-Exit griefing.** Sending extra tokens to someone could break their Auto-Exit approval. The fix is an unlimited (`u64::MAX`) delegate approval. * **Wallet compatibility.** Phantom adds Lighthouse instructions to transactions, which fail an instruction whitelist. Because any pre-graduation transfer path reopens PvP, Trucee tokens are non-transferable until graduation by design. ### Blinks Solana Actions that let people buy, or exit at cost, straight from a post on X. Cut on 2026-10-11 so that the web app is the one surface we finish for the hackathon. ### Leftover to Holders Unsold tokens left on the curve at migration would be claimed by a Trucee account and shared among holders pro rata by cost basis, the same way the buffer surplus is shared today. Cut on 2026-10-11. Trucee's preset uses a dynamic token supply, and with that preset DBC burns all unsold tokens at migration, so there is nothing left to share. Making it work would need a fixed-supply preset, two new instructions and a DAMM v2 pool in the test environment. ### Ideas without a design yet These ideas are listed in our plan by name only. They have no specification, code or tests yet: * **Borrow Your Floor** * **Fair Start**, built on DBC's activation point and batching * **Protected Fractionalization** * **Graduation Raise**, framed for real-world assets (RWA) ## Research ### Retention Fee Retention Fee: researched and built to a security review; the review found the push-based settle could let a creator block holders' surplus, so it was cut; the known fix is a pull model (creator claims, finalize snapshots buffer minus owed). The idea is to pay creators for buyers who hold, not for buyers who flip: * The market's share of DBC trading fees (80%; the protocol keeps 20%) would go to a Trucee-controlled account instead of the creator. * After the curve completes, the creator would be owed `fees × retention`, where retention is the share of all bought cost basis that is still held at graduation. * The rest of the fees, and all of DBC's partner surplus, would go to holders. In the reviewed design, a settle step pushed the creator's pay straight to the creator's token account. A creator can make that transfer fail forever, so settling never succeeds, and the surplus could never be finalized for holders. The pull model fixes this: settling only records what the creator is owed, the creator claims it with a separate instruction, and `finalize` snapshots the buffer minus what is still owed. None of this code is in the router source or on any network. Known caveat of the idea itself: round-trip flipping lowers the creator's pay, and a creator who buys and holds their own token raises it at the cost of locking up their own capital. ### Real-pool replay Our sniper numbers come from simulated order flow, not from real pools (see [Research & data](/research-and-data.md)). Replaying real mainnet DBC pools needs mass mainnet RPC reads and is planned for later. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.trucee.fun/roadmap.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.