> For the complete documentation index, see [llms.txt](https://docs.arcv.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.arcv.network/6.-protocol-economics-and-tokenomics/6.1-arcv-token-and-fair-launch.md). # 6.1 $ARCV Token & Fair Launch Archive Protocol separates its protocol token from its payment currency. Enterprise campaigns, contributor rewards, and native gas use USDC on Arc. $ARCV is the externally launched asset whose market supply may be reduced through the proposed revenue-funded acquisition and removal program. Holding $ARCV is not required by the current registry to create a bounty or receive payment. This chapter defines the ARCV launch policy and its verification requirements. It does not certify a completed launch. No ARCV-specific token bytecode, mint history, launch transaction, creator purchase, or graduation receipt has been established by this documentation release. ## Token specification | Parameter | ARCV policy | | ------------------------------------ | ------------------------------------------------------ | | Name | Archive Protocol | | Display ticker | $ARCV | | Initial issuance ceiling | 1,000,000,000 tokens | | Subsequent issuance | No mint function or other authorized inflation path | | Launch venue | faze.fun | | Network | Arc mainnet, chain ID 5042 | | Gas and protocol settlement | Native USDC | | Private pre-sales | None | | Venture discounts or pre-allocations | None | | Reserved locked insider allocations | None | | Token deployment | External launchpad token, not a custom registry ERC-20 | The token's decimals must be read from the deployed token. Native USDC's 18-decimal interface does not establish another token's precision. Express balances in integer base units and convert for display only. “Fixed supply” describes an issuance cap. If a genuine burn reduces totalSupply, outstanding supply will be below the original billion-token issuance. A no-inflation policy is compatible with declining outstanding supply; it is not compatible with undisclosed minting through an upgrade, privileged method, or alternative issuance path. Verification must inspect the actual implementation, ownership, upgradeability, and historical events. An absent function named mint is insufficient if another reachable operation can increase supply. The registry's arcvToken reference does not enforce the external token's cap or monetary policy. ## Fair-launch rules and distribution evidence ARCV's fair-launch policy excludes private discounted rounds, free venture allocations, and reserved insider vesting inventory. These are project commitments, not independently audited transaction history. Publish verified launch parameters and token supply evidence. Equal access to a pricing rule does not imply equal execution price or equal information. Earlier curve purchases can execute at lower marginal prices than later ones. Network latency, capital size, launch timing, fees, and automated trading affect participation. Creator first-buy arrangements or platform launch options must be disclosed if selected; they must not be silently described as identical timing for every participant. A launch reconciliation should show: * Total tokens created and their initial destinations. * Inventory available to the public curve and inventory reserved for migration. * Fees and any other privileged economics selected at launch. * Remaining curve inventory, distributed inventory, and migration inventory without double counting. ## Bonding curve inventory and capital flows [Faze's protocol reference](https://faze.fun/docs) describes a one-billion-token issuance, approximately 77.8% curve inventory and 22.2% graduation inventory, with automatic graduation in the purchase that completes the curve. These are platform descriptions; the selected ARCV launch record must establish its exact amounts and terms. Applied illustratively to one billion tokens, the approximate split is 778 million curve tokens and 222 million migration tokens. Approximate percentages are not an exact balance ledger. Read emitted launch terms and balances before publishing an exact distribution. ``` Public buyers supply quote capital | v selected faze.fun curve / \ public token distribution accumulated migration capital | | | reserved token inventory | | +----------------------> graduation pool | post-graduation trading ``` Curve inventory and migration inventory have different economic functions. Inventory reserved for a pool supplies liquidity rather than a locked insider grant. Accumulated curve capital may be committed to migration and therefore is not freely spendable protocol revenue. Circulating float requires a published classification policy. Tokens in wallets, curve contracts, pools, sinks, and custody accounts are observable balances, but “circulating” is not a single universal on-chain getter. A pool reserve is tradable inventory; excluding it as if it were an insider lock can misstate available supply. ## Pricing mathematics and executable quotes Let q be cumulative sold inventory and p(q) the marginal native-USDC price per token. Ignoring fees, the cost of a purchase is: ``` C(q, delta_q) = integral from q to q + delta_q of p(x) dx P_average = C(q, delta_q) / delta_q FDV_reference = P_marginal * initial_supply ``` These equations describe a general curve, not a verified implementation of Faze's pricing formula. A specific p(q), its parameters, integer rounding, and fee treatment must come from the token's deployed curve release. No ARCV-specific parameter set is certified here. Do not invent a linear or constant-product formula and use it to encode real purchases. For an increasing curve, the average price over a positive purchase exceeds its starting marginal price. The difference is price impact, which is distinct from slippage tolerance. Slippage tolerance controls how far execution may differ from a quote before reverting; it does not eliminate the curve's quoted price impact. For economic illustration only, if p(q)=a+bq, then: ``` C = a*delta_q + b*q*delta_q + (b/2)*(delta_q)^2 P_average = a + b*q + (b/2)*delta_q ``` This analytical model is useful for explaining why large orders cannot be valued at the initial spot price. It is not Faze's asserted formula. Production execution must use venue quotes such as quoteBuyFor or the supported SDK against current state and the actual buyer. Fees reduce net input available to the curve. Quote output, native value required, refundable excess, and completion behavior must be taken from the actual execution plan. A displayed FDV is not capital raised, pool liquidity, or the realizable value of all holders' tokens. For a quote returning Q token base units and allowed slippage s basis points, a typical minimum-output convention is: ``` minimum_out = floor(Q * (10000 - s) / 10000) ``` The application should use the SDK's verified minimum-output result rather than assume every venue implements identical rounding. Never set minimum output to zero for a treasury trade. ## Graduation and liquidity verification A token-specific bonding target is not a universal launchpad constant. Resolve the selected token's curve, quote currency, target, lifecycle, pool identity, and hook from its launch record. Faze's [developer reference](https://faze.fun/fordevs) directs integrations to use per-token routing metadata and re-resolve the venue when graduation occurs. ``` Curve trading | target-filling purchase | atomic migration in platform transaction | verify graduation receipt and pool identity | refresh quote and route v Uniswap v4 pool trading ``` Verify migrated native value, reserved token amount, any migration fee, pool initialization, position range, and custody restrictions from the actual receipt and state. A pool entry in an API is discovery evidence, not a substitute for chain verification. Uniswap v4 supports concentrated liquidity, but that does not establish that a particular position uses a narrow range. Faze's [launchpad page](https://faze.fun/) describes full-range liquidity. Record the actual ticks instead of turning a protocol capability into a claim about ARCV's launch position. ## /market route transition and execution The current frontend uses @fazedotfun/sdk version 0.5.1 and buildCurveTrade through src/lib/arc-swap.ts. It supports auto, curve, and dex selection, checks the token's active venue, requires a native-USDC quote asset, and checks configured destinations against discovered routing metadata. This code path is not evidence that ARCV has launched or that a specific live deployment has been funded. Before graduation, the configured curve address must match the token's curve. After graduation, the configured DEX destination must match the Universal Router. A mismatched forced mode rejects instead of silently sending to a stale venue. The builder requires one native-input transaction, checks chain, sender, destination, and value, and rejects an invalid minimum output. Uniswap v4 exact-input-single behavior is normally encoded as a V4\_SWAP command containing SWAP\_EXACT\_IN\_SINGLE and settlement/take actions, submitted through Universal Router execute. A v3-style external exactInputSingle ABI is not a drop-in replacement. PoolKey includes currencies, fee, tick spacing, and hook. The [Uniswap v4 swap guide](https://developers.uniswap.org/docs/protocols/v4/guides/swapping/swapping) documents this execution structure. On Arc, native input means USDC attached as transaction value. The route must preserve the pool's required hook data and token ordering. Native input does not require approval of an ERC-20 input balance; token sells can have different approval requirements and are not implied by the current buy widget. Refresh quotes after account, chain, amount, slippage, or lifecycle changes. A curve-completion race must trigger venue discovery and a new quote, not replay old calldata against a different contract. Success requires a successful transaction receipt and reconciliation, not merely a broadcast hash. ## Supply reporting and launch acceptance | Metric | Required meaning | | --------------------- | ----------------------------------------------------------------------- | | Initial issuance | Verified tokens created at launch | | Outstanding supply | Current totalSupply at a stated block | | Supply-reducing burns | Verified reductions through the token's supported destruction mechanism | | Dead-address holdings | Separate balance measure, not assumed totalSupply reduction | | Circulating supply | Explicit inclusion/exclusion methodology | | Pool liquidity | Actual pool reserves/positions, not FDV | A launch acceptance record needs the token address, chain, creation transaction, supply, decimals, implementation identity, selected economics, routing metadata, and migration evidence when applicable. Until that evidence exists, the specification remains a policy and integration design. Non-inflationary issuance limits dilution from new supply. It does not promise price appreciation, a minimum price, exit liquidity, or a return to holders. The enterprise-demand linkage is a proposed budget rule described in [Protocol Revenue Engine](/6.-protocol-economics-and-tokenomics/6.2-protocol-revenue-engine.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.arcv.network/6.-protocol-economics-and-tokenomics/6.1-arcv-token-and-fair-launch.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.