Skip to main content

Token Supply and Allocation

One Billion HYFY. Fixed Supply.​

HYFY has a total supply of 1,000,000,000 tokens, created once at launch.

The protocol operates under two foundational rules:

  • Zero Inflation: The total supply of HYFY can never exceed one billion. The underlying code contains no function to create or mint new tokens.
  • Deflationary Burns: Over time, the supply can only shrink. When tokens are burned, they are permanently removed from existence.

Tokens are not automatically circulating simply because they exist. They enter circulation gradually when they are released from restricted custody, for example through community claims, liquidity deployment, contributor vesting, ecosystem grants, or approved treasury distributions.

How the Supply Is Allocated​

The one-billion HYFY supply is divided across five core purposes designed to support the network over a multi-year horizon:

Allocation PurposeToken AmountShare of SupplyRole in the Network
Protocol Treasury Reserve500,000,00050%Long-term network security, stability, and future protocol initiatives
Community Claims Reserve200,000,00020%Rewards for authentic platform participation earned via in-app Karma
Liquidity Reserve100,000,00010%Supporting trading depth on decentralized and centralized exchanges
Contributor Alignment100,000,00010%Long-term incentives for the engineers, designers, and builders of HYFY
Ecosystem Development100,000,00010%Developer grants, creator funding, and strategic ecosystem partnerships
Total Supply1,000,000,000100%Fixed at genesis

Note on Float: An allocation is not the same as circulating supply. Tokens designated for treasury, vesting, ecosystem, or other restricted purposes are intended to remain outside circulating supply until released under their applicable custody or distribution rules.

What Each Allocation Is For​

1. Protocol Treasury Reserve — 50% (500M HYFY)​

This is the protocol’s long-term balance sheet. It acts as an enduring financial cushion to ensure the network can operate, scale, and defend itself across a multi-year horizon.

  • What it supports: Long-term infrastructure requirements, protocol obligations, emergency security reserves, economic stabilization mechanisms, and future protocol initiatives approved through the protocol's governance process.
  • Separate from team compensation: The Protocol Treasury Reserve is not the founder or contributor allocation. Founder, team, and advisor participation belongs within the separate 10% Contributor Alignment allocation.
  • How it moves: Reserve tokens remain subject to the protocol's custody, governance, and treasury controls. Authorized movements are recorded on-chain and can be independently reviewed.

2. Community Claims Reserve — 20% (200M HYFY)​

This reserve is dedicated exclusively to rewarding authentic, qualifying platform participation and social utility earned through in-app Karma.

  • Earned through participation: Community members qualify for token rewards by actively participating and earning Karma in the HYFY app.
  • 200 Million Lifetime Limit: There is an absolute, immutable lifetime ceiling of 200,000,000 HYFY that can ever be distributed through community claims. Once reached, no further community claim distributions can ever occur.
  • Monthly distribution: Community claims are distributed gradually through monthly claim periods rather than releasing the full allocation upfront. Monthly pools are paced by verified net platform revenue and account verification.

3. Liquidity Reserve — 10% (100M HYFY)​

To ensure people can buy, sell, and trade HYFY smoothly without excessive price slippage, the protocol reserves tokens to establish deep market liquidity.

  • Liquidity deployment: When liquidity reserve tokens are deployed, they can be paired with stablecoins such as USDC in exchange liquidity positions. Protocol-managed positions and their fees remain subject to the applicable treasury and liquidity controls.
  • Emergency release guardrails: Under the current liquidity policy, emergency reserve releases require sustained market-stress conditions, the applicable cooldown, and governance approval.

4. Contributor Alignment — 10% (100M HYFY)​

Incentivizes the software engineers, designers, researchers, and advisors who build and maintain the platform.

  • No Separate Founder Allocation: HYFY does not have a separate founder pool or insider round. All core team members, founders, and key advisors are compensated exclusively out of this single 10% allocation.
  • Long-term alignment: Contributor tokens are designated for multi-year vesting with lockup periods before release. Enforceable on-chain vesting is a production custody requirement rather than a restriction built directly into the HYFY token contract itself.

5. Ecosystem Development — 10% (100M HYFY)​

Dedicated to expanding the wider HYFY network and empowering external creators.

  • What it funds: Independent developer grants, open-source tooling, creator incentives, Pod seed funding, and strategic protocol partnerships.
  • Milestone-based by policy: Ecosystem funding is intended to be released in stages against approved grants, partnerships, or measurable milestones rather than distributed as an unrestricted pool.

When HYFY Enters Circulation​

It is easy to confuse total supply with circulating supply:

  • Total Supply: All tokens in existence that have not been burned.
  • Restricted Custody: Tokens held in protocol treasury reserves, contributor vesting contracts, lockup accounts, or dedicated ecosystem multisigs.
  • Circulating Supply: Tokens that are freely transferable and are not held in disclosed treasury, vesting, lockup, or other restricted custody.
Circulating Supply = Total Supply - Disclosed Restricted Custody

Minting the fixed supply to protocol custody at deployment establishes initial custody, not market circulation. Circulation begins only when an authorized claim transfer, liquidity seed, vesting unlock, or ecosystem grant actually settles on-chain.

Example Supply Ledger​

Assume total supply starts at 1,000,000,000 HYFY:

Action / MilestoneRestricted Protocol CustodyCirculating SupplyTotal Supply
Illustrative starting point1,000,000,00001,000,000,000
1,000,000 HYFY claimed by users999,000,0001,000,0001,000,000,000
500,000 HYFY added to public liquidity998,500,0001,500,0001,000,000,000
250,000 HYFY permanently burned from restricted custody998,250,0001,500,000999,750,000

Illustrative example: This ledger demonstrates how circulation and total supply behave; it is not a statement of current live wallet balances. It assumes no circulating seed liquidity at the starting point. Any liquidity already deployed into a publicly tradable pool would already form part of circulating supply.

Claims and liquidity move existing tokens into circulation. Only burns alter total supply.

Protecting Community Rewards​

HYFY reserves up to 200 million tokens for lifetime community claims. As users claim HYFY each month, the remaining community capacity falls.

The treasury architecture is designed so that non-claim treasury operations cannot spend the tokens required to preserve this remaining claims capacity. Even if the platform engages in other treasury actions, such as burns or liquidity additions, the contract mechanically safeguards the remaining community claims reserve. This ensures that community rewards cannot be diverted to cover other operational expenses.

Token Allocation Is Not Revenue Allocation​

It is vital to distinguish how fixed tokens are allocated from how platform revenue is budgeted:

Token Allocation ≠ Platform Revenue Allocation
  • The 50% Protocol Treasury Reserve describes how 500 million HYFY from the fixed supply is designated for long-term protocol reserves. It is not the founder or contributor allocation, and it does not mean HYFY receives 50% of platform revenue.
  • The 75% Platform Development, Growth & Operations figure describes how HYFY budgets off-chain platform revenue from Space Credit purchases. It funds real-world business expenses like cloud servers, mobile app-store fees, identity verification, engineering salaries, and customer support. It does not grant the operating entity ownership of 75% of HYFY tokens.

The platform does not receive "50% of the tokens plus 75% of everything." Token allocation concerns fixed token inventory; revenue budgeting concerns the cash flow required to operate the social network.

Governance, Custody, and Transparency​

HYFY balances cryptographic code enforcement with transparent operational governance:

  1. Smart Contract Enforced: Rules such as the fixed 1-billion maximum supply, the 200-million lifetime community claim ceiling, and treasury claims-reserve protections are hardcoded into smart contract bytecode.
  2. Policy & Production Custody Requirements: Contributor vesting, ecosystem allocation controls, and production multisig/timelock administration depend on the deployed custody and governance architecture. They should not be described as core-token restrictions unless the relevant production contracts and roles have been verified.
  3. On-chain transparency: Deployed contract addresses, token movements, and published governance/custody configurations can be independently verified on Polygon. Production role assignments, timelock settings, vesting contracts, and custody addresses should be published as part of HYFY's deployment disclosures.

Technical Verification (For Auditors & Developers)​

This section provides the underlying smart contract details, state variables, and verification references for technical reviewers and auditors.

Smart Contract Invariants​

  • Token Contract: HYFYToken.sol mints the fixed 1,000,000,000 HYFY genesis supply (MAX_SUPPLY) to the deployment-configured initial holder. No additional mint function exists.
  • Claims Capacity: HYFYTreasury.sol enforces the 200,000,000 lifetime claims cap via LIFETIME_CLAIMS_CAP. Claims are settled via transferForClaim(address user, uint256 amount), decrementing communityClaimsRemaining.
  • Reserve Protection: The view function availableHyfyBalance() calculates spendable balance as max(Treasury HYFY Balance - communityClaimsRemaining, 0). Non-claim operations (_burnTreasuryHyfy, executeEmission, addLiquidity) revert with WouldConsumeClaimsReserve() if they would leave the balance below communityClaimsRemaining.
  • Excess Burns: A hybrid mechanism. HYFYGovernance stores the configurable treasuryCapAlert parameter. The off-chain orchestration layer calculates whether spendable reserves exceed this cap and computes the 1% excess amount. HYFYTreasury.executeAutoExcessBurn enforces authorization, period idempotency, claims-reserve protection, and burns the submitted amount.

Allocation & Custody Summary Matrix​

Allocation PurposePolicy Amount (HYFY)Policy ShareCustody & Enforcement BasisFounder / Team Access?Genesis Float
Protocol Treasury Reserve500,000,00050%Enforced: 1B supply limit, claims capacity protection (availableHyfyBalance), excess-burn idempotency.
Policy/Launch Gate: Timelocked multisig governance. Core bytecode does not partition a 500M sub-balance.		Policy: No.
Contract: Recipient not restricted by bytecode.		0%
Community Claims Reserve200,000,00020%Enforced: 200M lifetime ceiling (LIFETIME_CLAIMS_CAP), settlement via transferForClaim(), spend protection.
Configurable/Policy: Monthly caps, KYC verification, revenue backing.		Ordinary user claims only.0%
Liquidity Reserve100,000,00010%Enforced: Treasury NFT tracking, fee collection, claims capacity protection.
Policy: 50/50 stablecoin pairing, emergency stress predicates.		Policy: No.
Contract: Recipient not restricted by bytecode.		Seed only
Contributor Alignment100,000,00010%Policy / Launch Gate: Sole team bucket; dedicated on-chain vesting contracts required at launch. Not enforced in core ERC-20 bytecode.Yes (Sole team bucket)0%
Ecosystem Development100,000,00010%Policy / Launch Gate: Milestone-based grant disbursements under multisig oversight. Not segregated in core bytecode.Policy: No.
Contract: Recipient not restricted by bytecode.		0%

On-Chain Verification Checklist​

  1. Supply Invariants: Verified via HYFYToken.sol constructor and absence of mint() functions.
  2. Claims Capacity Ceiling: Verified via HYFYTreasury.sol public constant LIFETIME_CLAIMS_CAP.
  3. Claims Capacity Protection: Verified via availableHyfyBalance() and WouldConsumeClaimsReserve() checks.
  4. Burns: Verified via on-chain TokensBurned events and decrements to totalSupply().
  5. Custody & Roles: Verified via on-chain role queries (hasRole) against published deployment registry addresses.