Trinity: a launcher backbone for small token projects

Draft research note · April 2026

Abstract

Trinity ($TRINI) is a token designed to function as the shared backbone of a token launcher: small projects launching on Base each include a $TRINI cross-pair pool in their Uniswap V4 hook deployment, which puts $TRINI to work as a quote asset for those projects' bonding curves. As successful launches generate organic trading activity, arbitrage flows pump $TRINI's price and lock $TRINI inventory inside the cross-pair pools. Quiet projects do nothing; active projects do meaningful work. Trinity captures the upside of every successful launch in its ecosystem without ever having to extract from any project's supporters.

We built a year-long simulator that models the cross-token dynamics between $TRINI and N launched projects, including the secondary effects on the $TRINI/USDC price discovery pool. The simulation shows that the design works only when there is asymmetry between project volume and Trinity volume — and that asymmetry is exactly what you'd expect from a launcher in operation. Six small-to-moderate projects with varied trajectories produce a +58% lift on Trinity's price over a year of simulated crab-market conditions, plus durable lockup of ~6.6% of supply.

This document describes the mechanism, presents the simulation results, walks through why the math works, and gives the design recommendations for the next-generation hook contract that will implement it.

1. The launcher problem

Most token launches force a project's founder into an extractive role. The founder holds a large fraction of the token they just created, so the only way to make project income is to sell some of their bag — which makes them a counterparty to their own community.

The alternative we're describing is a fee-based income model: deploy curve infrastructure that generates fees from organic and arbitrage trading. The fees pay the founder. The token's value comes from its utility plus burns plus scarcity. The founder never sells.

For this to work at the small scale where most projects actually live ($0–$100/day of organic volume in year one), the system needs to:

1. Generate meaningful fee income at small scale
2. Not extract value from the project's own users (no Type A leakage)
3. Capture value from external market movements (Type B arb income)
4. Scale gracefully as the project grows

The previous research note (epic-research) walked through what we tried first — discrete liquidity bands managed by a custom V4 hook — and showed that bands cause structural value leakage of ~50–65% on any meaningful trade. That design is dead. We've since rewritten the model around continuous concentrated liquidity positions (one big position per pool, no bands), which removes the leak entirely.

Continuous positions plus the multi-pool architecture gets us to the small-scale viability threshold: with $50/day organic volume, a project can generate ~$200/year in treasury fees while burning meaningful supply. That's good. But it doesn't capture the meta value of running many launches — and it leaves Trinity itself without a clear value model.

This document is about that meta layer.

2. The mechanism: Trinity as cross-pair backbone

2.1 The basic setup

Each project that launches on the launcher deploys a standard 5-pool curve set:

The EPIC/TRINI pool is the new piece. It's a continuous liquidity position with EPIC as the token and TRINI as the quote asset. At deploy time, the project owner sources ~$50 worth of TRINI from the TRINI/USDC pool to seed the cross-pair pool's quote side, so the pool can function as a real two-sided market from day one. (This is the only TRINI cost the project owner incurs.)

2.2 What happens in operation

In day-to-day operation, two flows interact:

Flow A: External pair asset moves. WETH, cbBTC, and CLANKER all have market prices that move on external venues. When any of them moves, the corresponding EPIC/<asset> pool's implied USD price for EPIC drifts. Arbitrageurs close the spread by buying EPIC from the cheaper pool and selling to the more expensive pool. This generates buy fees on the buy-side pool (paid in the quote asset, sent to the project's treasury) and burn-fees on the sell-side (paid in EPIC, sent to the burn address).

Flow B: Organic project trading. When a real user buys or sells EPIC on the EPIC/USDC pool, they create a temporary spread between USDC and the other pools. Arbs equilibrate. Same fee/burn dynamic.

The cross-pair EPIC/TRINI pool participates in both flows, but its quote asset price is dynamic — it's set by the current state of the TRINI/USDC pool, which lives in Trinity's own ecosystem. So when Trinity's own price moves (because of activity on TRINI/USDC), every project's EPIC/TRINI pool sees the move and arbs accordingly. Conversely, when arbs source TRINI to inject into a cross-pair pool, that buying pressure is real and shows up on TRINI/USDC.

2.3 The asymmetric flow that drives the lockup

Here is the key observation: when a project has more buy volume than Trinity itself, the project's USDC pool pumps. Arbs flow to equilibrate all the other EPIC pools, including the cross-pair pool. To bring the cross-pair pool's tick up, arbers must buy EPIC from it, which means they pay TRINI in. The pool absorbs TRINI.

Where does the arber's TRINI come from? They source it from the open market — specifically, the TRINI/USDC pool, which is the deepest TRINI venue. So a single arb cycle involves three legs:

1. Buy TRINI from TRINI/USDC pool (paying USDC) — pumps TRINI's price up
2. Buy EPIC from EPIC/TRINI cross-pair pool (paying TRINI) — locks TRINI in this pool
3. Sell EPIC to EPIC/USDC pool (receiving USDC) — closes the spread

After this cycle:

• TRINI/USDC pool has more USDC, less TRINI → Trinity's price has risen
• EPIC/TRINI pool has more TRINI, less EPIC → TRINI is now sitting in this pool (locked)
• EPIC/USDC pool has more EPIC, less USDC → its tick has come back down toward equilibrium
• The arber has earned the spread minus fees

Both effects on Trinity are positive. The price rises (durable, because the trade actually happened) and TRINI inventory accumulates inside the cross-pair pool (semi-durable, because the lock holds as long as the asymmetry continues).

2.4 What about quiet projects?

If a project never gets any organic activity, it never pumps its USDC pool, no asymmetric flow gets created, and the cross-pair pool sits inert. Quiet projects don't lock any TRINI. They also don't generate fee income — but that's the project's problem, not Trinity's. The launcher is unaffected.

This is the crucial property: Trinity scales only with successful projects, never with failed ones. There's no downside to listing dud projects — they just don't move the needle. The flywheel only spins when at least some projects are active.

3. Simulation methodology

We built a year-long simulator (scripts/simulate-launcher.mjs in the EPIC repo) that runs the full system over 365 daily timesteps. Key parameters:

• Total supply for both TRINI and each project's token: 100B
• Launch FDV: $1,000 (i.e., $1e-8 per token)
• Top FDV (range ceiling): $100M
• Pool architecture: continuous concentrated liquidity positions, one per pool. No bands. All EPIC committed contributes to L at every price point in the range.
• External pair asset volatility (annualized, applied to WETH/cbBTC/CLANKER):
  • WETH: 60% (representative of recent ETH vol)
  • cbBTC: 55%
  • CLANKER: 150% (memecoin-tier)
• Daily drift on pair assets: 0 (true crab market)
• Organic trading: 50/50 buy/sell, distributed across multiple small daily trades. Volume per project varies by scenario.
• Trinity organic volume: $50/day across all scenarios (modest baseline)

3.1 The TRINI-mirror correction

Earlier versions of the simulator had a bug worth calling out: the arb engine operated on each project's pools independently, without modeling the secondary effect on Trinity's own pool. When an arb cycle absorbed TRINI into a cross-pair pool, the simulator didn't realize that the arber had to source that TRINI from somewhere. Trinity's own price stayed flat artificially.

The fix: after each project's arb round, the simulator measures the change in cross-pair TRINI inventory (Δ) and applies a corresponding trade on the TRINI/USDC pool (buy if Δ > 0, sell if Δ < 0). It iterates until the system stabilizes within each daily step. This makes the model honest about the round-trip arb routes that touch both ecosystems.

The numbers in this whitepaper all reflect the fixed model.

3.2 Scenarios run

All scenarios use deterministic RNG seeds for reproducibility.

4. Results

4.1 Trinity-side year-end metrics

Key observations:

1. Asymmetry is a hard prerequisite for locking. Scenarios 1A and 1B (equal volume) lock zero TRINI. Scenarios 2/3/4 (asymmetric) lock substantial amounts.

2. TRINI's price benefits from launcher activity even though Trinity itself has constant $50/day volume. In scenario 4, TRINI ends at 23.40× launch despite Trinity's own organic activity being identical to the baseline 14.76×. The +58% lift is entirely attributable to the launcher backbone effect.

3. Trinity's treasury also grows (+51% in scenario 4) because the arb-driven trading on TRINI/USDC pays buy fees to Trinity's treasury.

4. Locked supply scales with project asymmetry. Scenario 3 (one wildly successful project at 10× Trinity's volume) locks 6.6% of TRINI's total supply on its own. Scenario 4 (six projects of mixed quality) locks 6.65% in aggregate.

4.2 Project-side metrics in the six-project scenario

The power-law distribution of returns is exactly what you'd expect from a launcher. ZETA — the highest-volume project — generates more treasury revenue ($1,639) than the bottom four combined, and locks more TRINI than the next two combined.

4.3 Sanity check on Trinity's lift

Without any launcher activity (scenario 1A), Trinity would end the year at 14.76× from its own organic crab activity alone. With six cross-paired projects, Trinity ends at 23.40×. The marginal lift attributable to the launcher is ~58%.

The mechanism is direct: arbs needed to source TRINI from TRINI/USDC pool 6 separate times per arb cycle (one for each project's cross-pair). Each sourcing was a buy on TRINI/USDC, pumping it. The cumulative buy pressure is what produced the 58% lift. Trinity itself didn't have to do anything different.

5. Why it works

The intuition is closer to how Curve's CRV / veCRV mechanics work than to a traditional bonding curve. With Curve, the value of CRV comes from being the gauge token across many pools — pool deployers and stablecoin issuers buy CRV to vote for emissions, and that buying creates durable demand for CRV regardless of any individual stablecoin's success.

The launcher mechanism here is similar in spirit but uses arb routes instead of governance. Each project's deployment commits TRINI to a position that must hold inventory to function. As project trading creates arb opportunities, arbers route TRINI through these positions, pumping its price along the way. The aggregate effect across N projects is roughly N times the effect of a single project (for projects of similar size).

Critically, the design works in three regimes:

There's no scenario where adding more launches hurts Trinity. The downside floor is "no benefit, no harm." That's a desirable property for any backbone asset.

6. Limitations and risks

We're being deliberately honest about what the model doesn't capture and where the design breaks down.

6.1 Locking is not permanent

The cross-pair pools are bidirectional market makers, not vaults. The TRINI inventory accumulates when project flow is asymmetric in TRINI's favor. If a project later experiences sustained net selling (organic users dumping), arbs flow in reverse and the locked TRINI gets released back into circulation. The locking is stable as long as the launcher ecosystem has at least some active projects with net buy pressure. It's not a hard 4-year veCRV-style commitment.

This is mostly fine for the design's stated purpose — the goal is for Trinity to capture value from launcher activity, not to enforce permanent supply destruction. If you want permanent locking, you'd need a separate vault contract on top, which isn't in the current design.

6.2 The model assumes idealized arb behavior

Real arbitrageurs face gas costs, MEV competition, bridge frictions, and the simple fact of having to notice the spread in the first place. The simulator assumes spreads above the fee floor are always closed instantly and completely. In practice, arbs are slower and more expensive than this. For very small projects, arb cycles below ~$5–10 in profitable spread won't get noticed by professional MEV bots and will just sit there. This means the early-stage launcher income is somewhat overestimated by the model.

The flip side: as the launcher grows and pool sizes increase, arb attention scales up too. Pools that consistently produce $20+ arb opportunities get watched.

6.3 The TRINI/USDC pool is the load-bearing assumption

Trinity's whole value capture story depends on TRINI/USDC being the canonical source of TRINI for arbers. If most TRINI liquidity migrates elsewhere (a competing DEX, a CEX listing, etc.), the buy pressure from arb sourcing fragments and the price impact on TRINI/USDC shrinks. Trinity needs to either be the deepest TRINI venue or accept that the launcher backbone effect will be diluted.

6.4 Bear markets unwind the lockup

In a sustained bear market for Trinity itself (e.g., the launcher narrative breaks, big holders dump on TRINI/USDC, price drops), the cross-pair pools' implied USD price for EPIC drops too. Arbs run in reverse — they BUY EPIC from cross-pair pools (paying TRINI which they then dump on TRINI/USDC). This amplifies Trinity dumps, the same way the lockup amplifies Trinity pumps.

The launcher mechanism is a directional amplifier for Trinity's price action, not a stabilizer. Holders should understand this asymmetry. In practice, the floor is set by the project ecosystem's aggregate organic demand — even in a Trinity drawdown, projects with healthy organic flow will keep the cross-pair pools partly populated.

6.5 The project ecosystem must be curated

Anyone can pair their token with any quote asset on Uniswap V4. To make Trinity the default launcher quote, there needs to be a real product that projects opt into — a deploy script, a frontend, a brand, curation. Without curation, the launcher backbone effect doesn't materialize because there's no concentration. Trinity-as-a-launcher is a product, not a passive token property.

7. Design recommendations

Given everything above, here's what we're going to build next:

7.1 New hook contract

The current TrinityHookV6 / V7 / EPIC hooks all use discrete liquidity bands. They leak. They go away. The new hook will:

1. Use a single continuous concentrated liquidity position per pool. No bands. No transitions. Standard V4 mechanics.
2. Take 1%/2% symmetric fees before the swap touches the AMM (same BeforeSwapDelta pattern as before).
3. Block external LP (BEFORE_ADD_LIQUIDITY reverts unless sender is the hook). Only the hook can mint into the pool, so curve depth is fully controlled by the deployer.
4. Optionally deploy with a quote-asset seed so the pool starts as a real two-sided position from day one (not single-sided EPIC at the bottom of the range).
5. Be parameterized so any project can deploy a copy with their own token + quote asset + fee config + range. No more hardcoded constants.

The new contract is small (~250 lines) and we'll write it next.

7.2 Launcher deploy script

A single deploy script that takes a project's parameters (token address, total supply, FDV range, initial seed budget) and deploys the full 5-pool set:

• Mint the standard pools
• Source the cross-pair seed amounts (~$50 of each quote asset, including TRINI for the cross-pair pool)
• Inject seeds to make all pools two-sided and functional from day 1
• Verify on-chain state and report deployment addresses

7.3 Trinity stays live

The current TrinityHookV6 is going to be replaced, not removed. We'll drain the existing band-based pools (the JSONs to do this are sitting in epic/scripts/teardown/teardown-trini.safe.json from a few days ago) and redeploy fresh continuous-position pools using the new hook. The TRINI ERC20 contract and the staking hub stay untouched.

7.4 EPIC is the first launch

EPIC will be the first project to deploy on the new infrastructure, including the EPIC/TRINI cross-pair pool. This serves as a real-money test of the launcher mechanism. If successful, additional projects can follow.

8. What this isn't

This isn't a yield farm. Trinity holders don't earn from a fixed emission schedule. They earn from organic launcher activity, which is highly variable and depends on whether real projects use the system.

This isn't a get-rich scheme. The numbers in section 4 show meaningful returns, but they assume sustained launcher activity. In a year with no launches, Trinity is just a normal token.

This isn't a permanent lockup. As discussed in 6.1, the lockup is conditional on continued asymmetric flow. It's an inventory management mechanism, not an escrow.

This isn't a substitute for project utility. Each project still needs its own reason to exist. The launcher just provides better economics for the founder than the standard "sell your bag" model.

9. Open questions for next iteration

• What's the optimal cross-pair allocation? We tested 1% of supply. Higher allocations would lock more TRINI per project but also expose the project to more TRINI-correlated price action. The right trade-off probably depends on project size and intended TRINI exposure.

• Should the cross-pair pool use a different fee than the other side pools? We've used 2% symmetric. A higher sell fee (more burn) might compound the lockup faster but reduce arb frequency.

• Multi-launcher backbone? Could the same project pair with TRINI and another launcher backbone token simultaneously? The math says yes, but the design implications need thinking through.

• Time-decay on cross-pair allocations? Could the cross-pair allocation be retired to a vault after some period (e.g., one year), turning the soft lock into a hard lock for stale projects? Worth modeling.

These are good problems to have. They imply a working mechanism, not a broken one.

Generated from scripts/simulate-launcher.mjs in the EPIC repo (private). Source data in scripts/launcher-results.json. The simulation methodology and core assumptions are documented in the script comments.