HUNT 백서 전문

uary 19, 2024. Total supply is read from the canonical Ethereum contract. HUNT on Base is bridged and backed 1:1: the HUNT held by the Ethereum → Base bridge stands for all of the HUNT on Base, so Base is accounted for inside that balance rather than added on top. See Base HUNT (Bridged). Three categories Every HUNT falls into exactly one of three live categories: Burned: removed from supply for good, by past burns or by sitting at the dead address. Locked: still exists but is committed: held by the Factory NFT contract, held by the Town Hall behind Main Buildings, time-locked in the Neverlose.money vault, or sitting in the reserves of Co-op and other Mint Club tokens on Base. Market circulation: what remains, held in wallets, on exchanges, and in liquidity pools. Notes on method: The HUNT behind Main Buildings counts as locked while it sits in the Town Hall, even after a Building's one- year lock-up ends. Migrated Buildings still count: their HUNT stays in the Town Hall. The HUNT behind Mini Buildings sits in the Mint Club reserve on Base and counts as circulating. Market circulation is computed from onchain reads. It is not an exchange-reported ﬂoat, and it may differ from third-party circulating-supply ﬁgures. None of this is a promise about price. 27HUNT TOWN DOCS The supply panel on hunt.town/factory, with figures at capture time Live figures Live burned, locked and circulating ﬁgures, split by chain: hunt.town/factory. The reduction from 500,000,000 to today's total supply is recorded event by event in Buyback & Burn. 28HUNT TOWN DOCS 0 3 · H U N T Buyback & Burn The quarterly buyback-and-burn program ran from 2020 to 2022 and has ended. Some HUNT is still burned in other ways, such as the HUNT burned for each Co-op project update. The historical record Since 2020, 16 recorded supply changes have permanently removed 301,087,312 HUNT, roughly 60% of the original 500,000,000 issuance. Every entry except the 88 HUNT reconciliation has a public record, most as an Ethereum transaction. Category HUNTremoved What it was End of ecosystem bounties (2020) 186,578,670 Retirement of the unissued bounty allocation Team allocation & second-round funding (2020) 100,000,000 Retirement of the corresponding allocation HUNT → MINT swaps (2021) 10,775,286 Community (7,183,524) and team matching (3,591,762) swaps at the Mint Club launch Quarterly fee-revenue burns (2020 to 2022) 3,733,268 11 quarterly burns funded by non-HUNT fee revenue Historical supply reconciliation 88 Residual closing the historical entries to canonical supply Total 301,087,312 16 recorded changes The two large 2020 entries are structural: they retired allocations rather than buying tokens back from the market. The quarterly entries from 2020 to 2022 removed supply using revenue the products actually earned. Every recorded change Newest ﬁrst. USD values are at the time of each event, rounded to the nearest dollar. Totals are rounded to the nearest whole HUNT. Date Event HUNT removed USD value at execution Record 2022-10-04 Q3 2022 non-HUNT fee revenue 55,349 $19,934 Transaction 2022-07-01 Q2 2022 non-HUNT fee revenue 47,690 $20,473 Transaction 2022-04-01 Q1 2022 non-HUNT fee revenue 26,264 $30,729 Transaction 2022-01-03 Q4 2021 non-HUNT fee revenue 62,729.9 $55,088 Transaction 2021-10-01 Q3 2021 non-HUNT fee revenue 37,267 $26,976 Transaction 29HUNT TOWN DOCS Date Event HUNT removed USD value at execution Record 2021-07-14 Q2 2021 non-HUNT fee revenue 82,759 $30,621 Transaction 2021-06-29 Team matching HUNT → MINT swap 3,591,762 $616,573 Transaction 2021-06-29 Community HUNT → MINT swap 7,183,524 $1,233,145 Announcement 2021-03-31 Q1 2021 non-HUNT fee revenue 31,989 $15,171 Transaction 2021-01-04 Q4 2020 non-HUNT fee revenue 96,994 $6,479 Transaction 2020-10-08 Q3 2020 non-HUNT fee revenue 112,357 $6,123 Transaction 2020-09-17 Team allocation & second-round funding 100,000,000 $9,129,100 Transaction 2020-06-12 End of ecosystem bounties 186,578,670 $433,523 Transaction 2020-06-01 Q2 2020 non-HUNT fee revenue 1,868,664 $5,126 Transaction 2020-05-27 Q1 2020 non-HUNT fee revenue 1,311,205 $2,673 Transaction 2020-05-27 Historical supply reconciliation 88 Not recorded None Total 301,087,312 The 88 HUNT reconciliation has no transaction of its own. It is the residual in the team's HUNT supply workbook that closes the historical entries to the canonical supply. The buyback-and-burn program has ended Product revenue now buys HUNT for the Factory NFT instead of burning it. That HUNT goes into the Factory NFT contract, where it raises the NAV per NFT for every holder. See The NAV Vault. Unlike burned HUNT, HUNT in the Factory NFT still exists: it backs the NFTs and counts as locked in Supply & Distribution. There is no schedule for these purchases and no ﬁxed amount. Nothing here is a commitment to buy, a yield, or a return. See Terms. 30HUNT TOWN DOCS 0 3 · H U N T HUNT as the Reserve Token HUNT is the reserve behind Co-op project tokens and other HUNT-backed tokens on Mint Club. The mechanism Project tokens in the Co-op and tokens created on Mint Club's HUNT-backed curves are minted against a bonding-curve reserve. When someone buys one of these tokens, HUNT ﬂows into that token's reserve and stays locked there while those tokens are held. When they sell, HUNT ﬂows back out. The Factory NFT holds HUNT too, on Ethereum. That HUNT is held by the Factory NFT contract rather than a curve reserve: Factory NFTs mint at NAV and burn for 95% of NAV, with no curve. Because HUNT has no inﬂationary emission, the only way new HUNT-backed assets come into existence is by locking existing HUNT. So: More project tokens bought → more HUNT locked in reserves. More Factory NFTs minted → more HUNT held by the Factory NFT contract. More net inﬂow into reserves and the Factory NFT vault → less circulating HUNT, concentrated backing behind everything that has been issued. Sells and burns release HUNT back out, so activity alone does not lower circulation. Why it matters Most onchain projects launch a fresh token and compete with every other token for attention and liquidity. The reserve model does the opposite: it links projects. Each builder runs an independent project with its own reserve, but every reserve holds the same asset. When one project grows, it locks more of the HUNT that backs all of them. This is the core of Hunt Town's thesis: a shared economy where the success of one project contributes to the strength of all of them, rather than fragmenting a community across disconnected tokens. 31HUNT TOWN DOCS 0 3 · H U N T Base HUNT (Bridged) HUNT is native to Ethereum mainnet and bridged to Base, so the same asset backs activity on both networks. Ethereum holds the canonical HUNT token and the Factory NFT. Base carries the day-to-day HUNT activity: minting and trading the HUNT-backed tokens of the Co-op and Mint Club. Backed 1:1 Bridged HUNT on Base is a representation of the canonical Ethereum token, backed 1:1. It is the same asset, usable in reserves and payments on Base. It is not counted twice in total supply. See Supply & Distribution. Bridging HUNT moves between Ethereum and Base through Base's canonical Standard Bridge. The supported route is Superbridge, an interface to that bridge. Background: announcement. The bridge and its interfaces are run by third parties, not by Hunt Town. See Terms. Addresses: Contracts & Addresses. 04 h402 Overview 33 Providers & Veriﬁcation 35 How Paying Works 37 For Builders 39 H U N T T O W N D O C S 33HUNT TOWN DOCS 0 4 · H 4 0 2 h402: Overview h402 is the Agent Capability Market Layer: the x402 capability store for agents. Mount it once, and an agent can discover, inspect, and pay for a whole market of capabilities: web research, onchain data, AI generation, maps, ﬁnance, security checks and more, without setting up each API separately. It is Hunt Town's product for the "Agent" half of the Builder & Agent Economy. The h402 home page The problem An agent that needs ten different services today needs ten integrations: ten sets of API keys, ten billing relationships, ten response shapes, ten SDKs. Every new capability is a new procurement problem, and none of it is something an agent can do on its own at machine speed. h402 collapses that into one integration and one payment rail. Three ideas Mount once. The agent reads one skill ﬁle, which teaches it to search the catalog, pick a provider and pay. From then on it reaches the whole catalog, and adding a capability later means nothing new to install. Veriﬁed providers, explicit choice. Every listed provider has been paid-tested with its real response stored as a sample. The caller compares samples and per-call prices and pins the provider it wants. See Providers & Veriﬁcation. Pay per call. Paid capabilities settle in Base USDC over x402, signed locally by the caller's wallet. No per- provider API keys, no subscriptions, no custody. See How Paying Works. 34HUNT TOWN DOCS The vocabulary h402 is task-ﬁrst: an agent looks for the outcome it wants, not the vendor who provides it. Term What it is Capability One task, named category/action , e.g. web/search . It describes the outcome, not the vendor. Provider One concrete implementation of a capability, with its own input schema, price, upstream service, and a stored real-response sample. A capability can have many providers. Call One request against one pinned provider of a capability. Every executable call names its provider explicitly. Catalog The curated index of capabilities and their providers, browsable by humans and queryable by agents. h402 lists only providers it has veriﬁed and does not crawl the web for endpoints. The capability catalog Capabilities are grouped into categories such as ai , web and crypto . The live list is in the catalog. Two sides of the market For agents and apps: mount the skill, search the catalog, call what you need, pay per call. Callers use the open-source @h402/cli , or embed the payment ﬂow in their own app with @h402/core . For API builders: list a capability and reach agent demand without building billing. See For Builders. Status h402 is live in beta at h402.hunt.town, so details can change. Developer docs: h402.hunt.town/docs. 35HUNT TOWN DOCS 0 4 · H 4 0 2 Providers & Verification A capability is a task. A provider is one concrete implementation of it. Before you pay, the catalog shows each provider's price, its input schema and a sample of a real paid response. That is enough to predict the cost and the shape of the result. Providers of one capability, compared side by side Selection is explicit Every executable call is pinned to one provider. The caller (a human, an agent, or the CLI on the agent's behalf) chooses the provider before the call. There is no request-time routing and no automatic failover to a different provider mid-call. Every successful response records which provider served it, how that provider was chosen, and how payment was handled, so each call can be audited afterwards. The recommended default The catalog recommends a default provider for each capability, ranked by live success rate, latency and price: a recommendation a client may pin, not a router. Verification is binary, and it is earned by paying There is no veriﬁcation score. A provider is either enabled or it is not, and enabled is the veriﬁcation signal: A provider becomes enabled only after a real, paid probe against its live endpoint, never from documentation, a mock, or an assumed response shape. 36HUNT TOWN DOCS The exact response body from that paid call is stored as the provider's sample. This is what the catalog shows you as a "real sample". A failed probe disables the provider. Quality score is a different thing Separately from veriﬁcation, each enabled provider carries a continuous quality score derived from live call success rate and latency. It is used for one purpose: ranking enabled providers so the catalog can recommend a default. 37HUNT TOWN DOCS 0 4 · H 4 0 2 How Paying Works h402 turns the HTTP 402 Payment Required status into a real payment handshake, built on the x402 v2 standard. The exchange is non-custodial: the caller's key signs locally and never leaves their machine. The handshake 1. Call. A normal request to the pinned provider. Free capabilities, and calls covered by credit, return immediately, with no payment step. 2. Challenge. If payment is required, the server returns 402 with the exact amount, the payee, and a short validity window. 3. Sign. The caller signs an EIP-3009 authorization over Base USDC for exactly the quoted amount. No funds move yet and no key is shared. 4. Settle. The caller retries with the signature attached. h402 veriﬁes the signature, then calls the provider and pays it. Only after the provider returns a successful response does the authorization settle into h402's treasury through the Coinbase CDP facilitator, and the result returns. If the provider call fails, the authorization is never settled and the caller is not charged. Where the money goes Two hops, deliberately separated: h402 pays the upstream provider from its own operating wallet when it makes the call: over x402 in Base USDC, or over Tempo MPP, depending on what the provider accepts. The caller's payment settles into h402's treasury afterwards, and only if the provider returned a successful response. The caller therefore signs one authorization, in Base USDC, regardless of how the provider behind the capability is paid. Pricing and fees A quoted price is the provider's price plus h402's markup of 5%. The markup is included in the quote, so the caller authorizes the ﬁnal amount and there is nothing added afterwards. Prices are denominated in USDC, which is what lets an agent reason about spend in dollars. Every payment is a one-shot, exact charge. Credits Callers can hold bonus credits, issued today as onboarding grants, which are drawn down before any USDC is charged. Credits used on a failed call are returned. 38HUNT TOWN DOCS Properties that matter for agents No charge for a failed call. If the provider call fails, the caller's authorization is not settled, and any credits used are returned. Bounded authorizations. Each signature covers a single quoted amount and expires quickly, so a stale one cannot be replayed for more than it authorized. No ambiguous charges. A request whose payment state is unclear is not forwarded; it is reconciled rather than retried against another provider. No double charges. A retried call is not charged twice, and the client refuses a new price challenge on a retry instead of paying again. 39HUNT TOWN DOCS 0 4 · H 4 0 2 For Builders The other side of the market is the API builders who supply capabilities. h402 gives an existing API a path to agent demand without building billing, key management, or a customer relationship for every caller. The Builders page What you get Per-call monetization. Your service is paid per call, over x402 in Base USDC or over Tempo MPP. No per- customer billing, no API keys to issue, no invoicing. Agent-reachable distribution. Once listed, your capability is discoverable by every agent that has mounted h402, found by the task it performs, not by your brand. h402 handles the caller side. h402 sits in front as the paid proxy: it presents the challenge to the caller, veriﬁes the caller's signature, calls and pays your endpoint, and settles the caller's payment only after your response succeeds. Callers always pay in Base USDC, whichever way you are paid. How a listing works 1. Expose an endpoint. One capability, one price, reachable over HTTP. 2. h402 adds it as a provider candidate for the matching category/action , with your native input schema and an example. 3. It is paid-probed, then ranked. A real paid call must pass before the provider is enabled, and its live success rate, latency and price decide whether it becomes the recommended default. See Providers & Veriﬁcation. 40HUNT TOWN DOCS How you get paid h402 pays you from its operating wallet when it calls your endpoint, over x402 in Base USDC or over Tempo MPP. The caller pays h402's treasury in Base USDC, and that payment settles only after your response succeeds. Your price is what you set: the caller's quote is your price plus h402's 5% markup, shown transparently before they authorize. Getting listed today Listing is currently reviewed by the h402 team rather than self-serve. Submissions go through the Builders page on the h402 site, and the team runs the paid evaluation before a capability appears in the catalog. 05 lpTOKEN.fun Overview 42 LP Vaults & Shares 44 Dual Launch 46 Fees & Economics 48 Risks 50 H U N T T O W N D O C S 42HUNT TOWN DOCS 0 5 · L P T O K E N . F U N lpTOKEN.fun: Overview One market. Two ways to take part: the token and its liquidity. The token has an LP. Now the LP has a token. On lpTOKEN.fun you can trade the coin, or hold its fee-earning liquidity as a transferable token of its own. lpTOKEN.fun won Best Uniswap Stack Contribution at ETHOnline 2026. The idea In a normal AMM market there are two very different positions, and only one of them is easy to hold. You can buy the token: simple, liquid, one balance in your wallet. Or you can provide liquidity, which earns swap fees but means managing an NFT position, a price range, and a rebalancing problem. lpTOKEN.fun makes the second position as easy to hold as the ﬁrst. A Uniswap v4 liquidity position is wrapped in an ERC-20, so the LP side of a market becomes a token you can mint, hold, transfer, and redeem like any other. How a swap feeds the pool and its lpTOKEN What that gives you Two exposures to one market. The token tracks price. The lpTOKEN share tracks the liquidity: it holds both sides of the pair and accrues swap fees. Fees stay in the vault. Swap fees earned by the position are not skimmed. They remain in the vault and back every share. A market from day one. Builders can launch a token and its LP together, with the initial liquidity permanently locked, instead of bootstrapping a pool afterwards. 43HUNT TOWN DOCS Two ways a market gets here Path What it is Dual launch Launch a new token and its LP vault together on the platform. Initial shares are permanently burned, and a one-sided launch position creates a ﬂoor that grows with volume. See Dual Launch. Curated LP vault Open a vault on an existing Uniswap v4 pool, so liquidity added through it is held as an lpTOKEN. No launch position, no ﬂoor: pure mint / redeem / compound. Where it runs lpTOKEN.fun is live at lptoken.fun on Robinhood Chain, Base, Arc, and Ethereum. New tokens launch against each chain's native currency: ETH on Robinhood Chain, Base, and Ethereum, and USDC on Arc. Contract addresses are listed in Contracts & Addresses. 44HUNT TOWN DOCS 0 5 · L P T O K E N . F U N LP Vaults & Shares An LP vault is the contract that turns a Uniswap v4 liquidity position into a transferable ERC-20. An lpTOKEN share card One vault, one pool, one position Each vault is pinned to exactly one pool. Its currency pair and fee tier are ﬁxed at deployment and can never be changed afterwards. Inside that pool the vault owns one position, whose price range is set once when the vault is bootstrapped and never changes. The vault contract is the ERC-20 contract and the position owner, so an lpTOKEN share is a direct pro-rata claim on the vault itself. What a share claims A share's claim is computed live from onchain state: its pro-rata part of the position's principal, pending position fees, pending launch-fee NAV and idle vault balances, in each of the pair's two currencies. Mint A mint deposits both sides at the vault's current ratio and issues shares in proportion. 45HUNT TOWN DOCS Redeem A redeem burns shares and pays out in kind: a proportional slice of the position's liquidity plus a proportional share of idle balances, in both currencies. There is no lockup and no admin approval; redemption is always available. Compound Fees earned by the position sit as idle balances until s