Revenue Model & Build Plan

Before we begin

This document explains how VoteBoxApp can pay for itself, stay affordable for poor communities, guarantee the founder's share permanently, and eventually hand control to its community — and what it would actually take to build.

Technical terms are explained the moment they appear, in blue boxes like the one below. Nothing has been simplified away; the detail is all here, just unpacked.

1 · How proposals get priced

Voting is always free. Only the person who creates a proposal pays. The question is how much.

Why a single flat price fails

Charging everyone the same amount — say 20 cents per proposal — sounds fair but isn't:

• It hurts poor communities most. Twenty cents is invisible in Spain and meaningful in rural Malawi. One price cannot be fair to both.
• It undercharges large organisations. A twelve-person gardening group and a city of 500,000 pay the same, even though the value they get differs enormously.
• It doesn't raise enough money. At realistic volumes, a flat small fee never funds the organisation.

The solution: price by how many people will vote

This is fair automatically. Small local groups with few resources land in the cheap tiers. Large institutions land in the expensive ones. And crucially, the platform never has to ask anyone how much money they have — which would be both intrusive and easy to lie about.

The finding that makes this work

Because a handful of large proposals bring in most of the money, the cheapest tier can be made almost free at virtually no cost to the organisation:

Compare the two approaches directly. The poorest users end up paying less than before, while the organisation earns roughly nine times more overall:

Suggestion: launch with just three tiers (Micro / Community / Institutional) rather than five. Simpler to explain, cheaper to check for errors, and more tiers can be added later without breaking anything.

Three layers of affordability

Cheap prices are the first layer. Two more make affordability reliable rather than merely low:

Together these mean the answer to "can a poor village afford this?" is never "it depends" — it is "yes, and if not, the platform pays for them."

2 · Protecting everyone from ADA's price swings

This volatility is a serious problem, and the fix is surprisingly simple once you see it.

The trick: which number you write down

At the moment the fee is defined in ADA — "1 ADA per proposal." The amount of ADA is fixed, so its real value floats up and down with the market. The organisation's income becomes a bet on the crypto market.

Flip it around. Define the fee in dollars — "$0.50 per proposal" — and let the amount of ADA change to match. Now the real value is fixed and only the ADA quantity moves:

The old way produces a six-fold swing in income for reasons that have nothing to do with how well the platform is doing. The new way produces a steady figure.

How the app knows the exchange rate

Whichever is used, set a hard floor and ceiling in ADA terms, so that a broken or manipulated price feed can never produce an absurd charge. And use an average price over time rather than the instant price, to smooth out momentary spikes.

Two things pegging does not fix

3 · When more people vote than expected

Someone declares a Community proposal for 500 people. It catches on and 3,000 people vote. What happens?

Why asking voters to chip in doesn't work

The natural idea is to let the extra voters contribute a few cents each. The arithmetic kills it:

It works in two other forms instead:

• One sponsor covers the whole shortfall. A single $1.50 payment is perfectly sensible — one transaction, one postage fee. This is the sponsorship mechanism already described.
• The organisation simply absorbs it. Honestly, this is probably the right default. The gaps between tiers are $1.50, $6.00 and $17.00 — trivial amounts.

The clean solution: settle at the end, not the start

Treat the declared tier as a deposit rather than a final price. When voting closes, the system compares what was declared against what actually happened:

The refund is what makes this fair. Because guessing too high costs you nothing, nobody has any reason to deliberately under-declare to save money. Honest estimation becomes the easy choice in both directions.

Stopping abuse, using reputation

The obvious cheat is to always declare Micro and let the organisation absorb the overflow every time. Reputation solves it neatly:

• Seed (brand new) — narrow allowance; must top up if they exceed it
• Sprout / Branch — moderate allowance
• Root (long history of honest declarations) — generous allowance, absorbed automatically

Repeatedly under-declaring damages your standing. This gives the reputation system real practical weight instead of being decorative.

4 · Guaranteeing the founder's share forever

The Perpetual Founder Fee (PFF) is the founder's permanent share of platform income. The promise is only as good as its enforcement — and right now it is enforced only by ordinary app code, which could be changed by anyone who controls the software.

The conflict — and how to resolve it

There is a genuine tension. If everything is frozen permanently, the future community-run organisation has no real power and is decorative. If nothing is frozen, the founder's share is just a promise that a future vote could delete.

This also settles the long-standing question of awkward split percentages. A 90/10 division is a whole, clean, easily audited number — which matters a great deal for something that can never be corrected once deployed.

5 · What can actually be built

Now the engineering reality. There is one hard problem that reshapes the whole build order, and it is better to meet it now than after six months of work.

Three possible ways around it

The insight that saves months of work

Build Contract A first. It delivers the on-chain founder guarantee — the headline grant milestone — and it stands on its own even if Contract B is postponed indefinitely.

Storing the proposal text

Two things must be right here:

• The declared tier and voter limit must be written on the blockchain itself, not only in the IPFS file. Smart contracts cannot read IPFS.
• Lock the reference code at creation time. IPFS files are effectively replaceable — editing produces a new code. Without locking it, someone could pay for a small proposal and then swap in different content afterwards.

6 · Who needs a crypto wallet

So yes — start wallet integration now, but build it as strictly optional. The app must remain fully usable with no wallet connected. Anything that breaks without one has been built the wrong way round.

7 · What the money looks like

Average income of $1.48 per proposal, and — because prices are pegged — these figures no longer move with the ADA market. Two growth scenarios are shown: a cautious one and a faster one. Both slow down and level off over time, as real adoption does.

Under the old flat fee, $10,000 a month would have needed around 62,500 proposals — realistically unreachable. Here it needs about 6,800.

The first year remains modest — roughly $1,000–2,500 to the founder. That is entirely normal for a new organisation, but it must be said plainly: grants and the NFT programmes are structural rather than optional for the first two to three years. The honest framing for funders is that fee income is designed to replace grant dependency over a three-year horizon, not to avoid it from the start.

8 · How hard is all this to build?

The first four rows are realistically 2–3 months of focused work and produce a working tiered system with a genuine on-chain founder guarantee. The complete vision is nearer 9–18 months, and Contract B is where the difficulty genuinely escalates.

Suggested order of work

9 · Risks worth stating plainly

Glossary