TRN Docs

Appearance

Roadmap · Codeology TRN suite ​

This is a working plan for the apps under the trn.codeology.co.nz umbrella. It is not TRN's roadmap; that's the chain's stewards' to publish. This is Codeology's roadmap against TRN: what's already built, what's actively in progress, and what's queued — laid out in the order that makes the most sense to actually implement in, given dependencies, blast radius, and time-to-value.

Apps live as siblings in the trn/ workspace and deploy as separate subdomains. The umbrella architecture is documented in the repo's CLAUDE.md.

Reading this page ​

Each row is one shippable unit of work. The order is the recommended build order — earlier rows either unblock later rows or pay back more for less work. Status legend:

  • Shipped — live in production.
  • Active — partially live, currently being iterated on.
  • Queued — designed and prioritised, not started.
  • Backlog — known want, not designed.
  • Open question — depends on a decision before it can start.

Each row also includes the primary TRN primitive it lights up, so it's clear which pallet/precompile is the source of truth and what would have to change on chain to break it.

Now (shipped & in active polish) ​

#StatusWhatTRN primitiveNotes
1Shippedhomepage (landing)noneStatic holding page.
2Shippedfuturepass dashboardpallet-futurepass + FP precompileEVM + Substrate balances, FP resolution, NFT thumbnails, activity.
3Shippedtokenspallet-assets + ERC-20 precompileBalances, transfers, LP token display.
4Shippeddexpallet-dex + DEX precompileSwap + LP.
5Shippedtradepallet-nft + ERC-721 precompileNFT marketplace, buy/sell flows.
6Shippedstakingpallet-staking + Vortex distributionValidators, delegation, Vortex.
7Shippedrootcom (chat)own lightcone transport (not Sylo)P2P channels, DMs, sync protocol v2, paywall scaffold.
8Shippedlightcone (in-browser P2P transport)none (off-chain)JSON-LD-over-SSE mesh; the substrate rootcom runs on.
9Shippeddocsn/a (this site)Comprehensive TRN reference.
10Activerootcom paywall (Stripe + tier gates)off-chain StripeCode shipped behind subscriptionEnabled flag; blocked on Lambda backend to accept tier and create the three Stripe products.
11Activerootcom Tier C secure DMsoff-chain (Yjs-synced keypair)Wire & key path shipped; activates when the user has a Tier-C subscription AND the peer has published secureDmPub in their directory entry.
11aShipped@gen3labs/futurepass-* deps wiredgen3labs-hosted FuturePass stackfuturepass/composables/useTrnBuilder.ts and useFutureverseSigner.ts were dynamically importing @gen3labs/futurepass-transact and @gen3labs/futurepass-signer but neither was in package.json — runtime would have thrown on the first submit-extrinsic call. Now declared (signer ^1.8.0, transact ^0.8.0). See the migration playbook for the wider context of moving off Futureverse-hosted infra.

Next (small, foundational — start here) ​

These are short, useful by themselves, and unblock most of what's below. Do them in this order even if you only have an evening.

12. Maintenance-mode banner (shared) ​

  • Status: Queued.
  • TRN primitive: pallet-maintenance-mode.
  • Why first: zero dependencies; useful in every app; one-evening lift.
  • What to build: a small composable + banner component (read maintenance state from the chain RPC, surface a non-dismissable banner when active). Lives once in a shared place — easiest is to put the composable in futurepass/composables/useChainMaintenance.ts and re-implement the trivial banner in each app, or publish a tiny shared package.
  • Acceptance: every app shows a visible banner within ~30s of chain entering maintenance mode; banner disappears within ~30s of exit.

13. Token-gating module (shared) ​

  • Status: Queued.
  • TRN primitive: derived from pallet-nft / pallet-sft ownership + ERC-20 balances via precompiles.
  • Why second: unlocks gated rootcom channels (Tier-A-paid users gating their channels by NFT ownership), unlocks asset-bound trade discounts, and any later "do you hold X to see Y" pattern.
  • What to build: useTokenGate.ts composable that takes a gate spec ({ kind: 'nft' | 'sft' | 'erc20', collection?, assetId?, threshold }) and an EOA/FP, returns reactive passes: boolean. One shared implementation; consumed first by rootcom's channel access list (extend the access body with an optional gate so the receiver-side filter can drop non-holders).
  • Acceptance: a rootcom channel can be configured to drop posts from anyone not holding a specified collection/SFT/ERC-20 minimum.

14. Soulbound flag in createnft + trade ​

  • Status: Queued.
  • TRN primitive: NFT/SFT pallet soulbound flag + ERC-5484 precompile (added v10.67.0, Mar 2025).
  • Why third: trivial extension once trade is in shape; signals you're current with chain primitives.
  • What to build: add a "soulbound (cannot be transferred)" checkbox to the mint flows in createnft/ and (if scoped) trade/. Add a small SBT badge on listings.
  • Acceptance: a minted soulbound token is visibly badged in trade/ and rejects transfer attempts client-side; the chain rejects them too.

Soon (medium lifts, high real-world value) ​

15. XRPL bridge UI (bridge-xrpl/ — new app) ​

  • Status: Queued.
  • TRN primitive: pallet-xrpl-bridge + relayer; XRPL IssuedCurrency.
  • Why before Ethereum bridge: most recently topical (Oct 17 2025 stuck-tx incident, ongoing infra fix per Shen). XRPL ↔ TRN is also the bridge users notice most because XRP is the network's gas-side asset.
  • What to build:
    • New Nuxt SPA bridge-xrpl/ mirroring the futurepass layout (same EIP-6963 + FP plumbing).
    • Deposit flow (XRPL → TRN): show user's XRPL address (they connect a wallet that signs an XRPL Payment); poll the bridge for confirmation; surface the resulting TRN asset balance.
    • Withdraw flow (TRN → XRPL): user picks asset, signs the TRN-side extrinsic, watches relayer status.
    • Stuck-tx escape hatch UI: surface the bridge state per tx, link out to the bridge contract on rootscan, give clear "still stuck → DM Shen" copy.
  • Dependencies: tokens/ already wraps asset balances — reuse those composables.
  • Acceptance: end-to-end deposit + withdraw, with a status screen that doesn't lie to the user when the bridge is unhealthy.

16. Ethereum bridge UI (bridge-eth/ — new app) ​

  • Status: Queued.
  • TRN primitive: pallet-ethy + Ethereum-side bridge contracts.
  • Why now: structural parallel to the XRPL bridge once that's done; lots of reusable code in the deposit/withdraw shells; growing demand as TRN's ROOT economics tie in to Ethereum L1.
  • What to build: same shape as bridge-xrpl/, but talking to the Ethereum-side relayer and the corresponding pallet-ethy extrinsics on the TRN side. Reuse the deposit/withdraw status component built in #15.
  • Acceptance: end-to-end deposit + withdraw across an ETH/ROOT pair.

17. SFT (ERC-1155) creation + trade ​

  • Status: Queued.
  • TRN primitive: pallet-sft + ERC-1155 precompile.
  • Why: trade/ is NFT-only today; SFTs are how editioned/quantity-bearing items live on TRN. The NFI ecosystem leans on SFTs heavily.
  • What to build: an SFT mint flow (collection, token-id, max supply, max-per-holder, soulbound flag from #14) — likely lives under createnft/ reworked, or its own sft/ app. Trade flow extends trade/ to filter and display SFT listings alongside NFTs (separate tab or unified list with a "supply" column).
  • Acceptance: mint a 100-edition SFT, list 10 for sale at a price, buyer can purchase a quantity, balances reconcile.

Later (niche, larger, or dependent on product direction) ​

18. Doughnut issuance / management UI (doughnut/ — new app) ​

  • Status: Queued.
  • TRN primitive: pallet-doughnut (delegated-authority capability tokens).
  • Why later: powerful but esoteric; user demand is small until there's a flagship consumer flow needing it. Most useful for app-builders wanting to do gasless/proxied action on behalf of an EOA.
  • What to build: a UI to mint a doughnut (specify holder, expiry, capability set), display active outgoing/incoming doughnuts, revoke an issued one. Acceptance is per-spec — the chain enforces the cap.

19. Marketplace royalty + admin in trade/ ​

  • Status: Backlog.
  • TRN primitive: pallet-marketplace (admin flows + royalty config).
  • Why later: the buy/sell flow exists; what's missing is the creator-side of trade — setting royalties, managing offers, accepting/rejecting bids in bulk. Comes after the gateway features above.

20. Validator-operator console (validator-ops/ — new app, or extend staking/) ​

  • Status: Queued.
  • TRN primitive: pallet-staking (operator-side extrinsics).
  • Why later: staking/ is delegator-side; running a node is a CLI workflow per current TRN docs. With Gen3Labs and TRN Labs bringing new operators online (per the handover timeline), there's a small but real audience for a web operator console: configure commission, set rewards destination, signal upgrades, watch slashing risk.
  • What to build: a thin admin UI that calls the validator-side extrinsics; doesn't replace the CLI but covers the day-to-day.

21. Partner Attribution dashboard ​

  • Status: Queued.
  • TRN primitive: pallet-partner-attribution (added v10.65.0, Feb 2025) + the FeeProxy split (v10.67.0).
  • Why later: only matters when you have partner accounts earning a fee share. If/when Codeology operates one, build a small partner/ view: signed-up partners, attribution stats, fee accumulation, withdrawal flow.

22. Crowdsale participation UI ​

  • Status: Open question — depends on whether anyone is running crowdsales on TRN that you want to support.
  • TRN primitive: pallet-crowdsale.
  • Why open: no current product driver; only worth doing once there's a live sale to participate in.

23. TRN RPC redundancy (config-level fallback or self-hosted node) ​

  • Status: Backlog.
  • TRN primitive: the public RPC endpoints — wss://root.rootnet.live/archive/ws + HTTP equivalent for mainnet, wss://porcini.rootnet.app/archive/ws for Porcini testnet.
  • Why later: every Codeology app reads chain state by JSON-RPC against single URLs. If either endpoint dies, all apps simultaneously lose on-chain reads. The migration playbook calls these the lowest-risk dependency (validator partners run them with skin in the game), but architecturally they're a single point of failure.
  • What to build: two options, smallest-first.
    • (a) Config fallback — store a list of RPC URLs per network in a shared runtimeConfig. The provider constructor (@polkadot/api's WsProvider + viem's http()) iterates the list and retries on connect-failure. Requires identifying 1–2 alternate public endpoints (rootscan, Subscan, gen3labs) per network. One-evening lift; no infrastructure work.
    • (b) Self-hosted full-archive TRN node — runs alongside the static AWS stack. Stronger but operationally non-trivial: ~4–8 cores, 200+ GB SSD, snapshot management, version upgrades that track the runtime. Defer unless (a) proves insufficient.
  • Acceptance for (a): kill the primary endpoint in DevTools network blocking; apps fall through to the secondary within a few seconds; reads keep working.

24. Mobile / React Native companion (open question) ​

  • Status: Open question — out of scope today.
  • TRN primitive: all of the above, accessed from a native shell.
  • Why open: the migration playbook flags that @futureverse/auth-react-native has no gen3labs fork as of capture. If a mobile companion ever lands, the options are: (a) author the RN auth glue against @gen3labs/futurepass-auth (~300 LOC upstream), (b) wait for someone in the community to fork it, or (c) skip Pass entirely on mobile and use injected wallets / WalletConnect. Currently no driver — no need to decide.

25. Pass-OIDC sign-in path (contingency) ​

  • Status: Open question — not wired anywhere today.
  • TRN primitive: OAuth2 against the gen3labs-hosted FuturePass issuer at https://futurepass.gen3labs.tech.
  • Why open: every Codeology app signs in via EIP-1193 wallets or the in-browser wallet. None use Pass OIDC. If that ever changes (e.g. an app needs "sign in with Google/X/email" to onboard non-crypto users), the prerequisite is registering an OAuth2 client at https://futurepass.gen3labs.tech/manageclients — old fv-issued client IDs do not work against the gen3labs issuer. Recording this here so future-you doesn't get stuck looking for the registration endpoint.

26. Sylo migration / coexistence ​

  • Status: Open question.
  • TRN primitive: pallet-sylo, pallet-sylo-data-verification.
  • Why open: rootcom is your own design and doesn't use Sylo. If Sylo gets active community development post-handover, decide whether to wrap it (a separate sylo/ app) or stay on lightcone. Doing both adds complexity for no clear win.

Order rationale (one-paragraph version) ​

Maintenance banner and token-gating module first because they're cheap and unlock features in everything you already ship. Soulbound flag next because it's a trivial mint-time checkbox once the gating module is in place. Then XRPL bridge because it's the most-cited public concern on the chain right now and it has clear deposit/withdraw user flows you can ship end-to-end. Ethereum bridge follows because most of the code is the same. SFT trade rounds out the asset story so trade/ covers TRN's full collectibles primitive. Everything below that is niche or dependent on a specific business decision and can wait until a real driver shows up.

What this page deliberately doesn't do ​

  • Doesn't put dates on anything. Estimating is a lie; this is an order, not a schedule.
  • Doesn't claim TRN's stewards have committed to any of these on their side. The chain primitives exist (or are landing) per the changelog and features docs; how soon they're production-grade is on the network, not on Codeology.
  • Doesn't try to be the master list of every TRN pallet. For that, see /reference/appendix-d-pallets and the runtime release notes in /changelog.

See also ​

Last updated:

Curated independently by Codeology. Source-attributed reference for The Root Network. Not affiliated with Futureverse / TRN Labs.

© 2026 Codeology. Content licenses follow upstream sources — see Sources.