Funding and the token

EPOCHE coordinates community participation by paying for useful work and funding bug bounties. Customers can purchase agent-code reviews with EPOCHE at dollar quotes. Contributor settlement uses the asset and conversion terms in the accepted quote. Holding the token alone does not grant repository, release, or treasury permission.

The selected recurring funding sources are a share of purchased review fees and a 1% buy/sell tax on the EPOCHE token. The tax applies to a covered buy and to a covered sell. When uncommitted reward inventory reaches its target and protected reserves have coverage, designated incoming fees and taxes go to a burn address. When inventory falls below target or reserve coverage fails, those inflows replenish the pool. The exact crossing and equality rules appear below.

Revenue and obligations

Keep customer service liabilities, operating reserves, accepted contributor payments, and uncommitted bounty funds separately accounted for. Customer top-ups can represent work still owed. Do not treat the full top-up as earned revenue available for bounties or burning.

The review-fee allocation must provide for inference, infrastructure, and other service costs. Select its exact fraction and accounting basis before enabling the automatic transfer. The operating portion continues to pay service costs while the designated pool portion follows the pool-or-burn rule.

Launch funding does not include a 5,000 USDC founder contribution from Bryan. Launch budgets must use actual funding. Public development can begin before funded rewards open, but compute and hosting still require an operating allowance.

Use a continuously replenished pool with recorded commitments. A budget ceiling is permission to spend up to a limit, not proof that assets exist. Available funds are assets the DAO can spend under their terms after existing obligations and required reserves are accounted for. New reservations must not promise funds already committed elsewhere.

Pool and burn routing

Use a token-denominated target for uncommitted EPOCHE reward inventory. Protect operating reserves and accepted liabilities through a separate reserve check. This separates the number of tokens retained for future rewards from the assets needed to meet actual payment promises.

The target counts spendable, unreserved EPOCHE assigned to the bounty pool. It excludes tokens already reserved for accepted work, disputed awards, or another restricted purpose. It excludes customer service balances, gas funds, and operating reserves. Those balances can share custody only if the accounting and permission checks preserve their allocation.

The reserve check establishes coverage for customer liabilities, due and conditional commitments, adopted remedies, and the operating and emergency targets. Cover fixed asset liabilities in that asset or under funded protection specified by the promise. Do not count a volatile token balance at an optimistic spot price as guaranteed dollar coverage. Token-quantity liabilities can be reserved in tokens under their accepted terms.

Apply this accounting rule to every pool-to-burn decision. The token target and the separate reserve amounts require funded operating estimates before activation. The burn decision uses the reserve check's current accounting revision and authenticated result. It does not continuously convert the inventory target into dollars through a price oracle.

Split an inflow that crosses the target. For illustration, an uncommitted balance of 900 EPOCHE, a target of 1,000, and an incoming allocation of 250 sends 100 to the pool and 150 to burning if the reserve check passes. These are illustrative token quantities, not launch settings. If reserves are short, all 250 goes to the pool pending the authorized remedy for that shortfall.

Compute each allocation against the latest balance and reservation state. Commit the allocation atomically where possible. Otherwise reserve the inputs and prevent another worker from using the same available balance until the transfer is reconciled. An unsolicited deposit or a retained shortfall inflow can leave the pool above target. The threshold governs designated incoming funds, so it is not a hard ceiling on all treasury assets.

Any new liability, reservation release, withdrawal, changed service promise, or expired reserve evidence invalidates the prior coverage result where it changes the calculation. If some obligations are recorded off-chain, the controller trusts the admitted accounting worker to report them correctly. State that trust boundary and reconcile assets against the ledger. The burn contract cannot discover an omitted customer liability from a balance read.

Keep reserve evidence short-lived under an explicit accounting policy. The founding proposal accepts it for at most 24 hours and invalidates it sooner when the relevant ledger changes. A stale result routes funds to the pool, where they remain available for correction. It cannot permit burning.

The pool is a temporary supply sink. It holds EPOCHE outside the market until reward payments make those tokens available to recipients. Burning permanently removes tokens from circulation. This mechanism does not guarantee a token price or a dollar value for the retained inventory.

For review fees received in another asset, the designated share needs an authorized conversion if it is to become EPOCHE for rewards or burning. Name that operation plainly. It spends earned service revenue buying EPOCHE, and the burn route then removes the purchased tokens from circulation. Conversion follows pricing, liquidity, and cost limits. Unconverted funds remain recorded separately and are not reported as burned.

Define covered buys and sells, collection points, permitted exemptions, and amendment authority in the token implementation. The selected 1% rate does not require a tax on every wallet-to-wallet transfer. Verify the actual chosen contract and trading routes rather than assuming a general fee-on-transfer implementation.

Token and settlement readiness

Retain the 1% buy/sell tax and EPOCHE review payments as selected product mechanics. Their activation requires a tested token and actual supported payment routes. The first release-controller rehearsal can run without issuing a token or relying on trading revenue.

Test the tax together with contributor payouts, customer payments, treasury conversions, and fee-funded burning. Include every tax, trading fee, slippage limit, rounding rule, exemption, and recipient net amount in the simulation. Verify each proposed router, bridge, or venue with the chosen implementation before relying on it. Confirm support for each specific route before using it.

For example, a sale with a gross value equivalent to $100 and only a 1% sale tax leaves $99 before other fees and price movement. If the quote promises $100 realizable after sale, the funding and conversion calculation must cover those costs. A promise of a fixed token quantity instead leaves the recipient with the disclosed exit costs and price exposure.

If no tested route supports the promised net payout within its limit, disable that settlement route. Use only an already funded fallback in the accepted terms or obtain a revised agreement. Governance can reconsider the tax if measured results make it unsuitable. A worker cannot waive the selected tax or invent a treasury exemption to make its payout test pass.

Launch funding can include trading receipts, outside funding, and review fees. Treat every source as available only when its assets and commitments exist. Simulated tax receipts can exercise accounting during rehearsal, but they are not revenue.

Collection procedure

Steps can execute atomically where the implementation permits. Their accounting effects must remain distinguishable even then. No step requires a vote merely to apply the active routing rule. Changing the rate, split, threshold, or authority uses F9.

Additional funding

Sponsorship, outside seed funding, prepaid service, and funded token allocations can support launch or a domain budget. State the assets received and what the funder receives in return. Funding need not buy governance influence. A prepaid service commitment needs a reserve for delivering the service.

Any proposed liquidity mechanism must identify who supplies spendable assets and what obligations it creates. Virtual reserves cannot pay an external invoice by themselves. Assess each liquidity proposal on its specified mechanism. Evaluate the concrete arrangement and its capital source.

Keep forecasts separate from funding authority. Model service volume, margins, trading receipts, token prices, and operating costs as scenarios. Enable commitments from actual covered funds. Yield, buybacks, or other treasury uses can apply to uncommitted assets only after the relevant budget decision.