How Deviant earns revenue and what it offers in exchange. Three primary streams, a tier ladder, a worked example, and a forward look at premium features.
This document is the project's internal reference for how Deviant's revenue model is currently structured. It identifies the three primary revenue components, the marketing tier ladder that governs founder-platform revenue sharing, and a worked example showing how value flows in a single transaction.
This document does not describe asset-class structural definitions (those live in the technical specification and the MBA Standard — Asset Taxonomy) and does not develop the project's positioning narrative (that lives in Deviant — Presentation and Comparison). Here: the operational mechanics of how revenue is generated and shared, in neutral terms.
A previous version of this material exists as deviant_revenue_mindmap.html, which lists six revenue streams under a flywheel framing. That document is being deprecated as the project narrows focus to the three primary streams documented here. The four deprioritized streams are noted at the bottom of this document as secondary or future considerations.
Deviant generates revenue from three primary streams. Each stream is paid voluntarily by participants in exchange for something the platform delivers — there is no extraction from non-consenting parties, and no stream depends on locking users into the platform.
Founders deploying MBA contracts (DEA, PLA, MCA, MTA) configure a founder fee on their contract — typically a small percentage taken on mint or swap transactions involving their asset. The founder fee is the founder's revenue from their own contract.
Founders may enroll their contract in a marketing tier. In exchange for distribution and visibility from the platform (placement in the wallet's discovery feed, marketing surface area, integration support), the founder voluntarily routes a percentage of their founder fee to the platform. The tier the founder selects determines the revenue share percentage.
Founders who don't want platform marketing pay nothing to the platform — their full founder fee remains theirs.
The wallet charges a flat 0.5% service fee on protocol operations executed through it — specifically MBA mint and swap transactions. The fee is paid by the user performing the operation and applies to all MBA classes, all founders, all configurations.
The fee compensates the platform for operating the wallet infrastructure: maintaining the swap mechanism, providing rate verification, handling display rules, and the broader integration work that makes MBA contracts usable via a single interface.
Users who don't want to pay the service fee can interact with MBA contracts directly through their own implementation. The wallet is one path to the protocol, not the only one.
The wallet offers a premium tier with access to features not available in the base wallet. Premium access is a recurring subscription paid by users who want the advanced capabilities.
The flagship premium feature currently planned is DRA — Dynamic Rate Asset with Escalating Rate: an MBA-family asset class whose rate follows a deterministic schedule set at genesis (instead of remaining constant for the asset's life). Suitable for use cases requiring rate appreciation by design — perpetual-bond-like instruments, escalating-yield positions, time-locked appreciation schedules.
Other premium features are planned. Premium users get access to advanced tooling, deployment helpers, and DRA contract deployment.
What each stream is paid for. Stream 1 buys distribution (founders get reach in exchange for revenue share). Stream 2 buys operational infrastructure (users get the wallet's machinery in exchange for a small per-transaction fee). Stream 3 buys advanced capabilities (premium users get features the base wallet doesn't expose, in exchange for a subscription). Each stream is bidirectional — there's something paid and something delivered.
Founders who choose to enroll their MBA contract in a marketing tier select from a ladder of options. Each tier represents a different trade-off between revenue share routed to the platform and the depth of marketing/distribution received. Tiers are voluntary, contract-by-contract, and adjustable.
| Tier | Revenue share | What the founder receives |
|---|---|---|
| None | 0% | Contract exists on-chain and operates normally. No platform marketing. Founder retains 100% of their founder fee. Suitable for founders who self-distribute or whose audience already knows their contract address. |
| Bronze | 10% | Contract appears in the wallet's discovery feed. Basic listing with name, rate, and supply information. Minimal placement priority. |
| Silver | 25% | Discovery-feed presence with elevated placement. Eligibility for featured-asset rotations. Integration-support resources for the founder. |
| Gold | 40% | Top-tier discovery placement. Editorial coverage in platform-published material. Direct integration support. Co-marketing opportunities. |
| Platinum | 50% | Featured-partner status. Highest distribution priority. Bespoke marketing collaboration. Strategic integration support. |
The tier system is one mechanism of the broader voluntary revenue-share design — founders can opt out entirely (Tier None) or step up to higher tiers as the value of platform distribution scales with their growth. The platform's revenue from this stream is therefore directly proportional to the value it delivers to founders — if the marketing doesn't generate distribution worth more than the revenue share, founders downgrade or exit the tier.
On tier specifics. The percentages and benefits above are illustrative of the model's structure. The exact percentages, the exact tier names, and the exact benefit packages are subject to refinement as the project scales and observes which trade-offs founders actually find worthwhile. The structural commitment is the voluntary, tiered, revenue-share-for-distribution exchange — not the specific numbers.
To make the three streams concrete, the worked example below shows the full fee flow when a user mints an MBA asset from a contract enrolled in the Silver tier. Numbers shown are illustrative — real magnitudes depend on the contract's rate, the user's mint quantity, and BCH network conditions — but the structural relationships hold for any mint transaction.
The contract is NCoin, a DEA-class asset (permissionless mint, fixed rate, unlimited supply). The founder has set a 1% mint fee on the contract and enrolled in the Silver marketing tier (25% revenue share to the platform). The user mints 100 NCoin, locking 10,000 sats of BCH into the contract at the configured rate.
| Token cost — BCH locked at rate | 10,000 sats |
| Founder mint fee · 1% of token cost | 100 sats |
| ↳ Founder keeps · 75% | 75 sats |
| ↳ Platform marketing share · 25% (Silver tier) | 25 sats |
| Wallet service fee · 0.5% of token cost | 50 sats |
| Miner fee (BCH network · approximate) | ~220 sats |
| Platform revenue from this single mint | 75 sats |
The platform receives 25 sats from the founder's marketing tier share + 50 sats from the wallet service fee = 75 sats total. The founder keeps 75 sats (their portion of the founder fee). The user pays 10,370 sats total — 10,000 going to the locked-BCH backing, 100 to the founder fee, 50 to the wallet service fee, ~220 to BCH miners. Of the 370 sats above the locked backing, the platform gets 75, the founder gets 75, the miners get the rest.
The split makes the three streams visible simultaneously. Stream 1 (voluntary marketing revenue share) produces the 25-sat platform share from the founder fee. Stream 2 (wallet service fee) produces the 50 sats directly from the user. Stream 3 (premium features) would appear here only if the user is a premium subscriber — that revenue stream operates at the subscription level, not the per-transaction level, so it doesn't show in a single mint flow.
The premium feature set is anchored by DRA — Dynamic Rate Asset with Escalating Rate. This is the headline feature behind the premium subscription and the project's first move beyond constant-rate MBAs.
What DRA does, at the business-model level: a DRA contract behaves like an MBA — the rate is set at genesis, the rate function cannot be modified after deployment, the contract operates without a custodian — but instead of a single fixed rate that holds for the asset's life, the rate follows a deterministic schedule. The schedule is locked at genesis (no party can modify it after deployment), but the rate value produced by the schedule changes over time according to the formula.
The "Escalating Rate" name describes the most natural use case: positions whose backing rate appreciates over time. A holder's claim on BCH grows as the schedule progresses. The financial character is similar to a perpetual bond or an inflation-protected security, but with structural enforcement instead of institutional commitment.
DRA's exact placement in the MBA Standard's asset taxonomy is not yet finalized. Three readings are open: (α) DRA is a separate fifth class in the MBA family; (β) DRA is a property modifier that can apply to any of the four existing MBA classes (constant rate vs. deterministic-schedule rate as a new axis); (γ) DRA expands to a parallel quadrant — four new MBA-with-schedule classes alongside the four constant-rate ones.
Each reading has different implications for the asset taxonomy and the technical specification. The decision is queued for development in a future turn. Until it is settled, this document describes DRA at the business-model level only — what it does, why users would pay for it, how the platform offers it as a premium feature — without committing to a specific structural definition.
When DRA's structure is settled: the MBA Standard — Asset Taxonomy document, the technical specification, and the relevant glossary entries will be updated. This document may need a corresponding pass to align with the resolved structural definition.
Premium subscription scope (in development). The premium tier provides access to DRA contract deployment (the structural addition above), advanced wallet tooling, deployment helpers, and additional features not yet specified. Pricing model — whether per-month, per-deployment, per-asset, or a hybrid — is under development as the feature set firms up. The structural commitment is that premium features are paid-access advanced capabilities, distinct from the base wallet which remains free at the operational level (the 0.5% service fee aside).
An earlier revenue model considered six streams under a flywheel framing. The current model narrows to the three primary streams documented above. The four deprioritized streams are listed below as secondary or future considerations — not abandoned, but not part of the primary focus during the project's current phase.
These streams may be revisited as the project scales and the conditions for their viability emerge. None is structurally precluded; they're simply not where the current revenue focus sits.
Revenue projections from this model require sizing assumptions — how many founders deploy contracts, how many users engage with each, what transaction volumes the wallet handles, what percentage of MBA activity flows through the wallet versus through other interfaces. These assumptions cannot be validated against current BCH on-chain activity alone (BCH on-chain is small and concentrated), and they require careful baseline-setting before projections become meaningful.
The companion document deviant_bch-baseline_FOR-internal-revenue-modeling.html establishes the BCH on-chain baseline for Phase 1 sizing — chain age, transaction-value distribution, active-address counts, the Phase-1 reach funnel, and the two-phase audience model. Revenue projections that ignore the baseline tend toward aspirational targets; projections anchored to the baseline produce more conservative but more defensible numbers.
This document does not develop the projections themselves. Sizing analysis sits in the baseline document; this document defines what generates revenue once activity occurs.