Proof Hunters white paper

1. Purpose

An NFT should have clear ownership rules and useful things its owner can do with it. Proof Hunters keeps the collectible at the centre: a Hunter is earned through proof of work, holds one basket type and carries its attached backing when ownership changes.

The ecosystem is designed to support mining, collecting, funded offers and borrowing. Actual service income can fund further backing, project reserves, developer compensation and operation of the platform. It does not promise increasing prices or investment returns.

2. The Hunter

The collection is Proof Hunters. The design retains a lifetime cap of 5,000 NFTs and proof-derived pixel artwork. Burning a Hunter does not reopen capacity under that lifetime cap.

The new product mines NFTs only. The intended settlement is one Hunter for each accepted product proof while capacity remains. It removes mined HUNTER rewards and the earlier HUNTER redemption reserve. Proof validation, difficulty and client behaviour must be implemented and tested together before release.

Mining has costs and competition. Faster hardware can have an advantage, proofs can become stale and another miner may submit first. Running a miner does not guarantee an NFT.

3. Basket identity and real backing

Each Hunter uses one basket-share token type. A basket can contain several underlying assets, while different Hunters can use different supported baskets. The collection is designed to admit additional reviewed baskets after launch without replacing existing NFTs.

Basket selection alone creates no backing. Only actual received tokens allocated to the NFT count. The accounting must distinguish owner-provided backing, funded ecosystem allocations and assets pledged in a loan. It must never count the same shares twice.

A basket share carries the rights specified by its own contracts. Its market value can fall. Token transfer restrictions, component issuers and redemption costs can affect exits. Backing is not a guaranteed currency value or fixed price floor.

4. Revenue and project funding

The planned income sources are reconciled creator-tax proceeds, fees on completed funded hunts, fees on successfully funded loans and later useful services such as convenient basket checkout. Loan fees are approved in principle; their amount and exact collection mechanism are not set. Checkout fees remain a proposal.

HUNTER is a separately planned ecosystem token. Its intended funding connection is creator-tax proceeds from the token launch venue. It is not mined by the NFT contract, required as an activation purchase or sealed as NFT reserves. No additional token utility or guaranteed demand is claimed.

The approved split of distributable ecosystem income is:

Distributable income means eligible receipts actually available after refunds, amounts owed to others, known obligations and directly attributable external collection costs. Costs must not be deducted twice. Basket acquisition costs are paid from the backing budget and reduce the shares delivered.

User deposits, NFT backing, loan principal, refundable offers and unpaid user credits are not income. Founder bootstrap funding is capital, recorded separately and not automatically split into compensation. Moving project money between its own accounts is not new revenue.

Creator tax is distinct from a developer fee paid by an external venue. If a combined receipt cannot be reliably classified, it remains unresolved in the source ledger. Manual funding from designated available project funds remains possible, but an on-chain deposit proves funding, not the original source’s tax classification.

The initial project funding process is manual. The four-way split is an approved policy, not a claim of deployed immutable enforcement. Future unallocated-income policy changes must be published; already allocated NFT backing cannot be reclaimed for project spending.

5. Daily rounds and equal allocation

The working daily cutoff is 00:00 UTC. Each round fixes an eligible cohort and its basket membership. New mints enter at the next cutoff. Delayed funding must use that original cohort rather than the population at deposit time.

Every eligible Hunter gets an equal acquisition budget, independent of rarity, chosen basket or existing backing. Basket-group budgets reflect the number of eligible Hunters in each group. Actual acquired tokens are shared equally within the group.

This gives equal spending budgets, not equal token quantities or future values. Different prices and conversion costs affect delivery. Rounding and unspent amounts must remain explicitly accounted for, without giving new entrants old allocations.

A daily cutoff is not an income guarantee or payment deadline. Only successful funded deposits count as backing. Unfunded eligibility must remain visibly separate from funded balances.

The proposed vault uses cumulative per-basket accounting and bounded settlement, avoiding a transaction that must visit every NFT. Accounting prototypes support further implementation work; they do not establish production correctness.

6. Ownership, redemption and switching

A transfer or sale carries the Hunter’s backing and unfinished allocation rights. A prior seller retains no separate claim against those rights.

Ordinary redemption burns the NFT and pays its available basket shares. Already-funded entitlements must not disappear during settlement. If a required transfer fails, the initial burn and payout must revert together, preserving ownership and backing.

Unfinished allocations from eligible pre-burn rounds remain claimable by the fixed final owner if those rounds receive funding later. Claims can be paid once. A burned NFT has no future daily eligibility. Redeeming basket shares into underlying assets is a separate operation under the basket’s rules.

An owner may request a basket switch only with no active loan and outside escrow. Earlier rights must settle correctly before a freshly approved conversion. Conversion costs and minimum output are shown to the owner, and resulting shares remain locked.

A pending switch can pause that Hunter’s new daily eligibility while retaining earlier rights. The owner can cancel. Completion or cancellation resumes eligibility at the next cutoff, with no catch-up for skipped rounds. The switching interface may ship later, but its required core capabilities must be proved before mainnet.

7. Hunter Bloom: whole-NFT loans

Use your Hunter to fund your next move. Bloom is a borrowing feature inside Proof Hunters; it does not rename the collection or token.

The planned direct-loan route pledges the whole Hunter. The borrower posts terms and a lender chooses whether to fund them. On successful repayment, the NFT and attached rights return to the borrower. On default, they transfer to the lender.

The collateral includes backing and allocation rights attached during the loan. The owner cannot simultaneously sell, burn, switch or pledge the same NFT elsewhere. The platform fee must be disclosed before funding and kept separate from principal and other user obligations.

External NFT lending markets remain a possible additional route. Their collection eligibility, network compatibility, custody and default terms must be verified. No provider listing or partnership is confirmed by this paper.

8. Hunter Bloom: basket-token loans

This route lets an owner authorise selected basket tokens as external loan collateral. The NFT survives, but is locked against conflicting actions while the position is active. The intended design supports one active loan position per Hunter.

New daily backing remains locally locked to the Hunter. The owner may explicitly add a bounded amount to the loan. Until a top-up confirms, those local tokens do not improve the external loan’s health. No automatic top-up is included at launch.

Liquidation can take some or all pledged tokens while the NFT survives. A surviving Hunter keeps its normal daily eligibility, with no replacement collateral, insurance payment or extra share. Future funding is not a guarantee of recovering losses or repaying debt.

A position closes only after actual debt resolution and restoration of recoverable collateral. Zero collateral does not prove zero debt. Recovery pending after repayment must be distinguishable from a fully closed position; a failed return cannot be reported as a successful unlock.

Token-market lending is an early delivery priority. Morpho is a research candidate, not a confirmed integration. A usable market requires the exact collateral asset, reliable pricing, a workable liquidation route and supplied loan funds. All supported basket types can be offered for loans; individual markets and lenders still determine acceptance.

9. Core contracts and later expansion

The architecture separates proof validation and minting, NFT identity and ownership locks, basket backing, basket issuance/redemption, funded offers, lending connectors and project funding.

Before the base contracts reach mainnet, the required interfaces must prove ownership checks, explicit collateral amounts, loan locks, repayment, liquidation and recovery. Connector admission alone must not grant arbitrary withdrawal rights over user assets.

New basket records and compatible connectors may be deployed or admitted later. Existing loan configurations and exit paths must remain intact. Avoiding replacement of the NFT and vault is the design objective; arbitrary future protocol compatibility is not guaranteed.

The interface and indexer help users see the system, but contract state is the authority over balances and permissions. Funded backing, pending rounds, posted collateral and debt must be shown separately.

10. Administration and treasury

The approved launch model uses restricted solo administration, with transfer to a multisig later. New reviewed baskets and permitted market configurations can be added without a waiting period. Admission must be publicly recorded.

The intended restrictions exclude taking user backing, rewriting balances, upgrading the core NFT/vault or changing existing loan terms. These limits and the role-transfer path still require implementation and tests. The product should not be described as having no administrator.

The team controls project funds before deposit and operates the frontend. External venues and underlying token issuers retain their own powers. Treasury custody and registry administration are separate responsibilities even if initially operated by the same builder.

Treasury savings fund continued development and low-income periods. Developer compensation depends on actual income rather than a promised salary. Reports should show receipts, obligations, allocations, deposits, retained funds, expenses and compensation by source.

11. Delivery plan

Foundation: complete the new core rules, backing accounting and required lending compatibility. Integrate and test real lifecycle flows, review findings and rehearse deployment.

Initial launch: verify the separate token launch and collection path, publish assets and contracts, and open NFT mining with usable backing, funding history and redemption. Usable funded basket backing is part of this release.

Early Bloom release: open verified basket-token lending and direct NFT borrowing routes as each has tested contracts, disclosed fees and actual liquidity.

Ecosystem expansion: add funded services, reviewed baskets, switching, suitable external markets and later multisig operations. Expansion follows actual demand and verified readiness.

These stages are dependencies rather than promised dates. The roadmap distinguishes current work from future services.

12. Limits and release conditions

Backing contributions may be small, delayed or zero. Basket prices can fall and issuers can restrict token transfers. Mining can consume resources without producing an NFT. Loans add interest, repayment obligations and liquidation or default risk.

Contract bugs, malicious integrations, unreliable pricing and unavailable liquidity remain material risks to test and review. A successful prototype or passing test suite is not a completed audit or proof of economic safety.

Before users can rely on a release, the project must publish verified network and contract details, selected baskets, applicable fees and route-specific terms. The new revenue-sharing and lending model also needs legal review before its relevant launch activities. No mainnet-ready, audited or guaranteed-return claim is made here.

The design record is the basis for this edition. Changes to product rules should be reflected in a dated revision, while preserving the distinction between agreed policy, implementation and verified deployment.