Protocol internals
Trinity is built directly on the official Uniswap v4 interfaces (IHooks, IPoolManager, BeforeSwapDelta). No interfaces are invented; the hook is a single-purpose fee router.
Architecture
componentsUniswap v4 & the PoolManager
v4 replaces per-pool contracts with a single singleton PoolManager. All state lives there; interactions happen inside an unlock callback where currency deltas must net to zero (CurrencyNotSettled otherwise). The pool is native ETH (currency0) / TRI (currency1).
The hook
Deployed at a mined CREATE2 address whose low bits encode its permissions — afterSwap + afterSwapReturnDelta. The constructor validates those bits via Hooks.validateHookPermissions, so a wrong address simply cannot be deployed.
Fee distribution
In afterSwap the hook computes 3% of the unspecified-currency amount, returns it as a positive hook delta, and take()s it as real ETH/TRI. The amount is split 1/1/1 into six accounting sleeves (burn/rewards/liquidity × ETH/TRI). Nothing price-sensitive runs here.
Rewards accounting
A magnified reward-per-share accumulator (magnitude 2¹²⁸). Shares = eligible balance, pushed by the token’s _update on every transfer. Distribution is one addition to a global; claims are derived on read. Excluded accounts and sub-threshold dust carry 0 shares. This is O(1) — holders are never iterated.
Liquidity management
processLiquidity unlocks the PoolManager, computes the liquidity the current price supports for the pending ETH/TRI, calls modifyLiquidity, and settles the owed deltas from the sleeves. The position is owned by the hook over a retunable band.
Burn mechanism
processBurn burns the TRI sleeve via ERC20Burnable, optionally converting the ETH-earmarked-for-burn sleeve first. There is no mint entrypoint — the supply integer is monotonically non-increasing.