More than creator tax
The ecosystem is designed to earn income from useful services as well as shared token creator-tax proceeds. More fee categories do not automatically produce revenue: people must use the services, and the project must actually receive the fees.
| Source | What produces income | Current position |
|---|---|---|
| Creator-tax proceeds | The project’s reconciled share from token trading | Planned external funding source; collection path needs launch verification |
| Funded hunts | A fee when an NFT offer is successfully filled | Fee path exists in source; revised product launch still pending |
| Hunter Bloom | A fee on a successfully funded loan | Fee approved in principle; rate and collection method unset |
| Basket checkout | A convenient basket purchase service | Later proposal; service and fee need approval and validation |
Founder bootstrap capital can also fund backing. It is labelled separately from earned revenue and is not automatically split into pay.
One income pool, four purposes
The approved allocation of distributable ecosystem income is:
| Purpose | Share | From 1,000 available units |
|---|---|---|
| NFT basket backing | 50% | 500 |
| Treasury savings | 25% | 250 |
| Developer pay | 15% | 150 |
| Running costs | 10% | 100 |
The example is allocation arithmetic, not forecast income. These are approved policy percentages; deployed automatic enforcement is not being claimed.
Distributable income is received eligible income after refunds, amounts owed to others, known obligations and directly attributable external collection costs. Developer pay and the same running costs cannot be deducted twice. Basket acquisition costs come from the backing budget and reduce shares delivered.
Creator tax and developer fees are different
Pons developer fees are recorded separately from creator tax. A verified developer-fee entitlement does not enter the ecosystem split unless it is explicitly contributed.
If a payment combines amounts and its exact split cannot be verified, we record it as unresolved. We do not label the whole receipt “creator tax” or count it twice.
The project can still manually fund the vault from clearly designated available funds. A vault deposit proves the backing was funded; it does not prove the original source was creator tax.
User assets never become operating money
The project must keep NFT backing, owner deposits, unfilled offer deposits, loan principal and outstanding user credits separate from business funds. None enters the revenue split.
Once backing is allocated to an NFT, it cannot pay hosting bills, developer compensation or treasury expenses. Moving money between project accounts is not new revenue.
A treasury that supports the product
Treasury savings support future development, security work and periods of low income. Running costs cover ordinary operation of the platform. Developer pay compensates the builder for ongoing work.
Revenue-linked pay is not a guaranteed salary. No funded reserve target or runway is claimed. If revenue is low, the project must reduce spending or use disclosed project funding, rather than take user backing.
What we plan to publish
Funding records should link received income and its source, available funds, the four allocations, basket acquisition costs and actual deposits. Treasury reports should show retained balances, spending and developer payments by source.
Policy changes must be published for future unallocated income. They cannot claw back earlier NFT allocations. Funding may be small, delayed or zero.