P3 Design Note — Fee Attribution, Curated Staking, and Value Distribution.

[robertocarlous]

P3 Tokenomics Notes — Alignment with the a16z Tokenomics Framework

Following up on the a16z tokenomics piece Abraham shared and the discussion thread, I compared the proposed framework against our current P3 tokenomics design.

✅ Where DIN Already Aligns

Two-Step Fee Model

The two-step fee model described in the article maps closely to what DinFeeRouter already implements.

Protocol fees are routed in a single execution across configurable buckets:

• Validator Pool
• Treasury
• Storage Reserve
• Public Goods
• Burn (currently disabled)

This mirrors the article's separation between fee capture and programmable fee distribution.

Value Distribution

DIN is already aligned with the direction the article recommends.

Instead of distributing protocol revenue directly to token holders, fees flow to:

• Validator Pool
• Treasury

Both are stakeholder-accountable destinations rather than passive holder rewards.

Structurally, this is much closer to Aave's Safety Module (where stakers assume risk and earn rewards) than to a dividend model. It would be worth making this explicit in the public design docs instead of leaving it implicit.

---

The Gap: Curated Staking & Fee Traceability

The most interesting gap the article highlights is traceability and curation.

Today:

• Validator staking is a single shared pool.
• Fees originate from allowlisted contracts.
• Revenue is distributed without attribution to individual models or model owners.

A curated staking model would instead allow validators to stake toward individual models (or model owners) via DINModelRegistry rather than one network-wide pool.

Benefits

• Validator incentives align with the performance of specific models instead of network-wide averages.
• Fee flows become attributable—you can trace revenue from a particular model to the validator and treasury allocations it generates.
• It better matches the "models belong to the commons" vision, where each model has its own staking constituency instead of relying on a shared pool.

Existing Building Blocks

Most of the infrastructure already exists:

• DINModelRegistry already maintains per-model metadata.
• DinValidatorStake already includes modelMinStakeBounds storage introduced during the P3 staking work.

The remaining work is primarily wiring these components together and enforcing model-level staking.

---

❌ What Doesn't Translate

The DNS certificate registry discussed in the article is primarily designed for consumer-facing applications, where discovery and frontend authenticity are important.

That doesn't map particularly well to DIN.

Our primary participants are:

• Model owners
• Validators

—not end users browsing a marketplace.

The registry pattern itself is probably not applicable, but the broader ideas around fee attribution, traceability, and incentive alignment are highly relevant.

---

📌 Suggested Next Steps

• Decide whether curated staking belongs in P4 or P5. It depends on task-contract enforcement, which is already identified as follow-up work after modelMinStakeBounds.
• Add a short section to the public design docs explaining the Aave Safety Module analogy and why protocol fees are routed to stakeholders instead of passive token holders.

---

Overall, I think we're already aligned with the core economic direction of the article. The main opportunity isn't changing the fee model—it's improving attribution, curated staking, and making those incentive flows observable.

@abrahamnash @umermjd11 @Santiagocetran