Native utility exists when users must hold or spend your token to access core protocol functions. But not all native utility is equally valuable.
Forgd evaluates native utility strength along two dimensions: How essential the token is to the user experience, and how popular the underlying product is.
| Low Token Essentiality | High Token Essentiality | |
|---|---|---|
| High Product Popularity | Large audience, but the token is easily bypassed, value capture leaks to alternatives. | Best case: Large audience that must use the token, strong, durable native demand. |
| Low Product Popularity | Worst case: Small audience + optional token = no demand floor. | Captive but small audience, demand ceiling is low even though usage is mandatory. |
Plot your project honestly on this matrix. The top-right quadrant (high popularity and high essentiality) is the gold standard. Solana's gas fee model is the canonical example: Every transaction on the network requires SOL, and the network processes millions of transactions daily.
Native utility categories to evaluate:
| Utility Type | Token Essentiality |
|---|---|
| Gas Fees | High: Mandatory for every transaction. |
| Fee Discounts | Low-Medium: Users can transact without holding, but pay more. |
| Restricted Access | High: Token required to use the product. |
| Governance | Variable: Often optional in practice. |
| Collateralization | Medium-High: Required for specific protocol roles but not all users. |
| Network Security | High: Validators must stake to participate. |
How to self-assess: Ask yourself, "If the token didn't exist, could users still access 90% of the protocol's value?" If yes, your native utility is weak, the token is a bolt-on rather than a requirement. Consider whether gating core functionality behind token ownership is viable without deterring adoption. If the product isn't popular enough to justify gating, you may need to rely more heavily on synthetic mechanisms and institutional partnerships for demand.
