Skip to main content

🔥🔥🔥 Accrual Plan

Below I tried to capture 🔥🔥🔥’s plan regarding the liquidity pool. Tldr - “two-pool + buyback” approach plan that splits the liquidity across a primary SOL-based pool and a secondary ai16z-based pool, with a built-in buyback mechanism for $ai16z. This design aims to encourage more projects to launch quickly (using SOL) while automatically channeling a portion of fees back into ai16z—creating a flywheel effect that benefits both the new Agent Tokens and the ai16z ecosystem overall.

1. Main Idea​

  • Use SOL as the “base currency” when projects (“agents”) launch new tokens (called “AT” or Agent Token).
    • These new projects all create SOL:AT trading pools
  • Once a project launches, the DAO automatically starts receiving transaction fees from the SOL:AT trading pool.
    • The SOL fees earned are used to buy back $ai16z from the open market.
    • Then, the newly purchased $ai16z is combined with the AT fees to create a second pool: $ai16z:AT.

By doing this, $ai16z gains buy pressure from SOL fees, while the new Agent Token (AT) gets extra liquidity paired with $ai16z. Both the newly launched AT and $ai16z get more volume and deeper liquidity.

2. Why Two Pools?​

  1. Primary SOL:AT Pool
    • Easier user experience, because most people on Solana buy new tokens with SOL. Benefit from the network effects of the L1 asset, is scalable across numerous L1s.
    • Minimizes volatility for the new project token, differentiating from competitors.
    • Lowers friction (no complicated “must buy $ai16z first” requirement), simplifying the process for new agent developers looking across ecosystems for a home.
  2. Secondary $ai16z:AT Pool
    • Funds itself automatically by taking fees from the primary pool.
      1. Users and projects don’t need visibility, think of it like a positive sum volume hack.
    • Creates additional routes for trades, arbitrage and volume, which can drive more fees (ex. arbitrage bots will balance the prices between the SOL:AT and $ai16z:AT pools).
      1. The DAO can deploy it’s own arbitrage swarm to tighten arb if needed.
    • Increases buy pressure on $ai16z
    • Increases liquidity and volume for AT, providing stronger markets to performant teams

3. High-Level Fee Flow​

  1. User swaps in the SOL:AT pool
    • Some fraction of fees (from that pool’s trades) is collected.
      1. 50% SOL and 50% AT.
  2. Treasury automatically buys $ai16z with the SOL fees.
  3. Remaining AT fees (collected from the SOL:AT pool) are paired with the $ai16z newly purchased in Step 2.
  4. Combined fees either form or grow a $ai16z:AT pool
  5. (Optional) A portion of fees can also be directed to:
    • A general DAO treasury.
    • Locked/staked $ai16z
    • Future incentive programs or “farming” rewards to deepen liquidity.

4. Key Benefits vs. a “Single-Token Launchpad”​

  • Lower barrier for devs: They can list a new Agent Token with a SOL pair—no forced purchase of $ai16z, which might scare off some projects.
  • Better for $ai16z: Even though devs do not need to hold $ai16z upfront, fees automatically get converted into $ai16z, so $ai16z gains consistent buy pressure without impact UX.
  • Positive-Sum Flywheel: More Agent Tokens launching → more trades in each SOL:AT pool → more fees → more $ai16z bought → more liquidity for $ai16z:AT → more fees, etc..
  • Simplicity: Users typically trade with SOL anyway; everything else (the second pool, etc.) is abstracted away.

5. Points Still Under Discussion​

  • Agent Creation Fee: Whether or not new Agent Token creators must pay an upfront fee ($ai16z) (for spam-prevention or “skin in the game”)—the group is leaning toward minimal friction.
  • Exact fee splits: What do we do with fees on transactions? What % goes toward buybacks versus other opportunities? When creating pairs, which side do you adjust to fit for LP?
  • Lockups: Should part of the $ai16z purchased be locked in a treasury to reduce sell pressure?