DHO Pricing Model

Purpose

Hypha product development teams have been heads down refining and improving our products. Each team has created outstanding roadmaps, reliable testing procedures, and efficient source control and deployment processes. This document is looking at how we can define revenue streams (i.e. relying less on investors and investment income) by coming up with a pricing model that is aligned with the regenerative renaissance (i.e. not driven by excessive profit motives), while at the same time paying for our infrastructure costs and rewarding all participants fairly.

Assumptions

We need to generate sustainable revenue streams that can cover expenses
We don’t need to decide the prices now, just put a framework in place
Circular economies require revenue
The customer wants to pay for features s/he needs
The RR (regen renaissance) wants to support it
The VP (value proposition) is clearly defined
Exact pricing should be part of governance (need to define who/how)

Potential Models

Freemium (Max: not feasible until we can reduce our costs per new DHO via automation; orgs need skin in the game);
SBP - subscription-based pricing (also on top of a Freemium model, typical SaaS model);
UBP - usage-based pricing (also on top of a Freemium model, typical on-demand model);
VBP - value-based pricing (let the customer decide, see deck below from CAWW);
PPS - paid premium services that are only sold to premium users (mostly providers);
PBU - price by users; (no go, see article by David Sacks below)

Notes on models

Freemium Grants

Instead of "free usage until you cross a threshold" or "hidden admin features" we can just issue grants (coupon) for N number of no-fee transactions.

Variations on UBP usage-based pricing (via Max)

3.1 pay per proposal;
3.2 pay per claim;
3.3 pay per feature;
3.4 pay per redemption (free for EOS);
3.5 pay-as-you-go, although may require a deposit, as well as pricing at broader levels

Premium access features

5.1 Connection to DeFi exchange
5.2 Accounting module
5.3 Incorporation (e.g. as Wyoming DAO)

Premium access pricing can be based on one-time setup fees or additional subscription pricing

Also to consider are options around longer commitment, annual vs monthly.

Teams vs Individual Licenses

Team plans are where the opportunity is, and therefore where founders should focus their energy and resources. Individual plans can be useful to generate leads, but their long-term revenue potential is significantly smaller. Account-level churn rates for Individual plans are commonly around 5% per month, but only 1-2% per month for Team plans. Team plans build on a solid long-term foundation whereas Individual plans are the definition of a Leaky Bucket.

Article: https://sacks.substack.com/p/individuals-or-teams-whos-the-better (via Augusto)

Process

1 select new DHO (e.g. via impact metrics)
2 set pricing model (and other params)
3 propose and launch DHO from parent DHO (hand over protocol)

Tokenomics

1 What tokens to use
2 Staking vs burning
3 Cost of services (infrastructure/capital, labor/roles)
4 Financial/knowledge/value/credit flows
5 Treasury/Store of value

Basics of Hypha tokenomics (Rieki)

Hypha token system accounts:

Access.hypha or stake.hypha (staking)

Staking for the organisation DHO accounts:

"Access level 1"
N staked = contract ABC available and XYZ limits (example: access roles, assignments, contributions (everything we have now) and a limit of 20 (will need to test and tweak) proposals a week).

"Access level 2"
N staked = contract ABC available and XYZ limits (example: access quests, new voting modules, rewards payouts (e.g. dividends), etc and a limit of 50 (will need to test and tweak) proposals a week).

"Access level 3"
Etc

^^ all that we'd need above is for each contract we build for us to decide which access level it falls into and limit use only to the orgs in that access level.

Start here:
https://docs.google.com/spreadsheets/d/1toeX1icHDK5Qi85xzw_PhctGZgeITulAEByyn9SLzuE/edit#gid=0

Then we can tweak the access levels (e.g. opposed to saying an org needs to stake 50 Hypha to access Y contract. We say they need to have access level 2 to access (and we can easily change the 50 stake to 75 for that access level)

---

Use.hypha or fees.hypha (fee account) (only recipient able = DAO.hypha or, with

"pay rewards" action = all Hypha is distributed proportionally to Hypha stakers...

"Burn rewards" (needed?) Action = all Hypha in account burned.

"Get Loan" action (for treasury management and more) = receive HUSD at max N% of staked Hypha value. Unable to unstake the collateral amount (or just at all for simplicity?) Whilst a loan is out.

"Mint Voice" action (optional?) = Mints N% voice every N period for staked Hypha (a method to create voice holdings based on weighted equity commitments over time!)

We could have a "Voice Faucet" that's distributed to Hypha stakers (e.g. solving that tension @max-g where investors have no voice). So, stakers earn voice by staking Hypha.... Could be a way for others to start having a bit of voice here by committing financially...

We govern the impact of this tool by tweaking the emission rate of Voice to the Hypha stakers (could have a floor to ensure adequate voice to stakers).

Pair this with a increased decay of Voice for inactive Voting and we have a way for those who drop away to have their voice transitioned.

"Cash out" by unstaking Hypha and selling it (end your share of voice disturbution from the staking faucet) and your voice gradually wanes away.

Hypha Tokenomics Model

Our Model (TBD)

How much "basic usage" can we afford and where is the threshold to UBP?
Are accelerators using VBP or other pricing model (T&E, Flat Rate)?
Is there revenue sharing between Hypha and Partners? (blue/orange and green boxes)
Is there a pricing policy needed and an agreement with Hypha?
Should we also have a commission program for sales reps?