P3 fees & treasury: fee lines, fee-router contract, DIN denomination (P3-5.3)

[umeradl]

Part of the P3 mechanism-design push (#36).

Summary

Model owners should pay for the network services they consume, with a slice of every flow sustaining a real treasury. Today only ETH registration/manifest fees exist in DINModelRegistry, withdrawable by owner() — no per-GI service fees, no treasury, no routing.

Scope (from MECHANISM_DESIGN §8)

• Fee lines: model registration fee (open-source vs proprietary tiers, reroute to treasury), manifest update fee, per-GI service fee (one flow with the reward-pool deposit: 95% validator pool / 5% treasury), storage-cost line item (design the routing slot now, hold at 0 until Filecoin migration — RES-1), dispute bond (returned + bounty if upheld, treasury if frivolous)
• Fee-router contract: single router with DAO-settable basis-point split fractions modelOwner → {validatorPool, treasury, burn, storage} summing to 100%; sane hard bounds only (e.g., treasury cut ≤ 20%). ✅ Resolved (Abraham, 2026-07-21): add a publicGoods slot to the split ({validatorPool, treasury, burn, storage, publicGoods}) now — it doesn't need to be funded immediately, but the slot needs to exist or it never gets built later.
• Denomination: registration fees are ETH today, staking/rewards are DIN. ✅ Resolved as a split, not "DIN for all protocol fees" as previously recommended here (Abraham, 2026-07-21): on-chain protocol fees (registration, manifest updates, staking, rewards) → DIN; validator network fees (model owner → validator, i.e. the per-GI service fee, storage line item, dispute bond) → stay in ETH — model owners already pay gas in ETH, and requiring DIN just to pay validators adds friction the depositAndMint on-ramp doesn't fully remove. Migration path: DIN params for the protocol-fee lines only, deprecate their ETH variants after one release; the network-fee lines have no ETH-to-DIN migration. The fee router must handle both assets going forward — accepted complexity, not deferred.
• Burn policy: ✅ Resolved: burn a fraction of both on-chain protocol fees and validator network fees (dual sources), start at 0%, keep the hook — in addition to the slashed-stake burn share (see P3 slashing: conditions taxonomy, penalty tiers, slashed-stake destination, dispute resolution (P3-4.1/4.2/4.3) #38, P3 tokenomics: token utility, emission schedule, supply policy, treasury (P3-5.1/5.2) #42).
• Dynamic fees: admin/DAO-settable base rate + per-role multipliers; no algorithmic fee logic in 2.0 — parameterize now, automate later

Design sources

MECHANISM_DESIGN §8 · issues/tokenomics.md (fee routing scope) · whitepaper-summary §5 (network fees as validator revenue; quadratic public-goods funding stance)

Roadmap anchors: P3-5.3 (fee mechanism), P3-5.1 (governance hooks), RES-1 (Filecoin storage cost slot)

[robertocarlous]

Hi @umeradl ,

Pls i need some clarification on this

1. DinFeeRouter initial split values

The spec says fractions are DAO-settable, but what are the deployment defaults? For example, is the ETH split {treasury: 500, validatorPool: 9000, storage: 0, publicGoods: 500} basis points? Need concrete numbers to write initialize() and tests.

2. validatorPool — what address does the router actually send to?

The fee router routes a slice to "validatorPool" but that concept has no backing contract yet (reward settlement is out of scope for this task per the summary). Does validatorPool point to DINTaskAuditor? A placeholder address set by the deployer? Or is it a no-op accumulator until the reward contract lands?

3. DINModelRegistry DIN fee UX — one function or two?

Does the DIN-denominated path mean a new requestModelRegistrationWithDIN() overload, or does the existing requestModelRegistration get a usesDIN: bool parameter? And does the ETH path stay fully functional in parallel for this task, or is it deprecated here?

4. DinCoordinator ETH rerouting — push on each call or accumulate then redirect?

Two options: (a) depositAndMint forwards ETH to DinTreasury immediately on every call, or (b) ETH still sits in DinCoordinator and the existing withdraw() is changed to send to DinTreasury instead of owner(). Which?

5. jailValidator / reactivate — explicit owner function or fixing the implicit path?

Currently jailing is implicit (stake drops below min → Jailed state). "Make jailing real" — does this mean adding an explicit jailValidator(address validator, uint64 duration) callable by owner/slashers, plus a reactivate(address validator) that a validator calls once their jail period expires and they've re-staked? Or is it only fixing the reactivation path on the implicit jail?

6. task_210726_5.md is referenced but not in the repo

The issue says "The task file has the full specification — exact contract code, function signatures, deployment/wiring order, and test plan." That file doesn't exist in Developer/tasks/ on develop yet. Should I wait for it before starting, or proceed from the issue description alone?

[umeradl]

Hi Robbert, answers below — the task file is now on develop: Developer/tasks/task_210726_5.md. It's the source of truth going forward if anything here conflicts with the issue body.

1. DinFeeRouter initial split values
Concrete numbers, from initialize():

• dinSplit = DinSplit(validatorPoolBps: 9500, treasuryBps: 500, burnBps: 0, storageBps: 0, publicGoodsBps: 0)
• ethSplit = EthSplit(validatorPoolBps: 9500, treasuryBps: 500, storageBps: 0, publicGoodsBps: 0)

So 95/5 validatorPool/treasury on both assets at deploy time. Burn starts at 0% (hook exists, off by default — "start at 0%, keep the hook"). Storage/publicGoods are reserved at 0 for now — same logic as the public-goods routing slot Abraham asked us to reserve now and fund later. All DAO-settable after deploy via setDinSplit/setEthSplit.

2. validatorPool destination
No backing address yet — it's a no-op accumulator, not a transfer. routeFeeDIN/routeFeeETH add the validatorPool (and storage/publicGoods) slices into accruedDin[keccak256("validatorPool")] / accruedEth[...] mappings inside DinFeeRouter itself. Nothing gets sent to DINTaskAuditor or any placeholder address. Those buckets sit there until a future sweep function exists — either the P3-5.2 reward-settlement work (task_210726_6 / issue #41) or a later emission contract. Nothing to wire on your end beyond incrementing the mapping.

3. DINModelRegistry DIN fee UX
Two new functions, not a bool flag: requestModelRegistrationDIN() and requestManifestUpdateDIN() are additive new entrypoints. They don't touch ETH at all — same registration/validation logic as the existing functions, but the fee comes from openSourceFeeDIN/proprietaryFeeDIN instead of msg.value, pulled via feeRouter.routeFeeDIN(msg.sender, requiredFee) (which does a transferFrom, so callers must dinToken.approve(feeRouterAddress, amount) first — the approval is against the router, not the registry). That DIN then gets split per the DIN split config from Q1 (treasury's cut is in DIN, not ETH), and the request is flagged via modelRequestPaidInDIN[requestId] = true.
The existing ETH entrypoints (requestModelRegistration/requestManifestUpdate) keep their current signatures and stay fully functional in parallel — not deprecated. Their ETH routes through routeFeeETH (split per ethSplit, no burn field) if a router is wired, or stays in the registry's own balance via the legacy withdrawFees() path if not. The two rails never mix — it's one function or the other, not a flag on a shared function.

4. DinCoordinator ETH rerouting
Option (b). depositAndMint() is unchanged — ETH still accumulates in DinCoordinator's own balance on every call. withdraw() (owner-only) is what changes: it now sends the contract's full ETH balance to treasury instead of owner(). No per-deposit forwarding.

5. jailValidator / reactivate
Explicit function, not just a fix to the implicit path. jailValidator(address validator, uint64 duration, bytes32 reason) is external onlySlasherContract — same allowlist slash() already uses, so it's called by registered slasher contracts, not owner() directly. reactivate() is self-service: it acts on msg.sender (not reactivate(address validator)), and only succeeds once jailedUntil has passed and the caller's stake is back above MIN_STAKE.

6. task_210726_5.md missing
Landed on develop this morning (commit c003ff1), linked above. Pull latest and it'll be there — go with the task file over the issue description if they ever diverge; this reply is also now a record of the parts that weren't fully spelled out in the file itself.