GitHoodBuilder markets
→ docs
A plain explanation of the current GitHood launch pattern, what the hook does, how fees reach a treasury, how support allocations are described, and which parts are live versus still upcoming.
GitHood is a builder funding system. A builder can launch a token, trade it through a Uniswap v4 pool, and route a clear part of trading activity to a public project treasury.
The first GitHood token is the proof of the pattern: fixed supply, no presale in the design, and a 4% funding fee split between the builder treasury and the shared GitHood treasury.
A builder fills in the launch form with project details, token name, supply, treasury wallet, funding fee, and an optional GitHub repository.
When the launcher contract is configured, the wallet transaction deploys a fixed-supply builder token and records the launch. Pool setup and launch liquidity are handled after the token deployment confirms.
A hook is code attached to a Uniswap v4 pool. It can run during a swap, so the fee route is enforced by the pool path instead of by changing normal token transfers.
For the GitHood design, exact-input trades route 4% of the ETH side through the hook: 3% to the builder treasury and 1% to the shared GitHood treasury.
The hooked pool splits the funding fee between the project treasury wallet and the shared GitHood treasury. Both destinations are meant to stay visible beside incoming fees, support allocations, and spending notes.
In the current v1 design, the GitHood treasury is a wallet. The support program does not change token transfers or deploy a separate payout contract, so any allocation still needs clear public reporting.
The GitHub connection gives the launch a public work feed. A repository can show commits, releases, and project activity next to the token and treasury data.
GitHub does not control funds and it is not a guarantee that work is valuable. It is context that helps people compare market activity with visible shipping activity.
Enter the project, token, treasury, fee, website, and repository details.
Use the connected wallet to deploy the builder token when the launcher is configured.
Register the funding hook route when the shared hook address is configured.
Initialize the ETH / token pool and add launch liquidity after the token exists.
Publish the builder profile once real token, hook, treasury, and GitHub data are available.
The important point is traceability. Funding enters through the hooked trading path, with 3% landing in the builder treasury and 1% in the shared GitHood treasury. Both flows should be shown beside project work instead of hidden in a private update.
The token itself should remain a normal token. The funding rule belongs to the Uniswap v4 pool path, which makes the route easier to explain and audit.
→ next surfaces