The community slice on every transaction can follow the buyer's community or the merchant's community. The choice sets what community operators are paid to do, and it decides whether a new community can fund itself from day one.
Situation. Kiota now runs multiple communities, and a second member community is landing. Each community holds a treasury that receives a percentage slice of transaction value. Today that slice follows the buyer's community of record, signed off by Kyne on 11 July. Once members and merchants sit in different communities, that ruling starts to have real consequences, and the alternative (routing to the merchant's community) was explicitly left open at the time as a possible future slice type.
Every commission structure declares slices by role. One of those slices, historically called the DCO slice, is the community's cut. The mechanics are settled. What is not settled is which community it belongs to once buyer and merchant sit in different ones.
Answering it forces an answer to a prior question: is a community treasury a member welfare fund or a local economy development fund? Look at what it actually pays out today, that is onboarding credits, deposit matches, referral bonuses and top-ups, and the answer is member welfare. Every liability on that fund is denominated in members.
That matters because a fund whose obligations scale with member count, but whose income scales with local trade, can write cheques it cannot cash. The reverse also holds. Whichever side we pick, the fund's income base should track the thing it is obliged to pay for.
Same transaction, same rate. Only the destination of the community slice changes. Rates shown are illustrative.
Community A hosted the trade, supported the merchant and carries the merchant relationship. It receives nothing. Community B, which recruited the member, banks the slice.
Community B recruited, onboarded, KYC'd and supports the member. It receives nothing from that member's spend. Community A, which built the trading network, banks the slice.
Whatever the slice follows, community operators will optimise for it and ignore the rest. Both options therefore leave one of the two growth activities unpaid.
Capitation model · revenue ∝ members × their spend, anywhere
Acquiring model · revenue ∝ GMV hosted at your merchants
This is the sharpest practical difference. Buyer-side routing produces treasury income as soon as members spend, and then flattens as the member base matures. Merchant-side routing produces almost nothing until merchants are trading, then compounds if the community becomes a trading hub. For a platform in expansion mode, the early part of that curve is what decides whether a community launch is viable.
Illustrative model showing shape, not measured data. Indexed so that 100 equals a mature community's steady monthly inflow. Assumes the community recruits members steadily from launch and acquires merchants more slowly.
| Month | Option A, buyer | Option B, merchant |
|---|
The consequence is a choice about who carries a new community through its first months. Under buyer-side routing, the model does it. Under merchant-side routing, Kiota's own treasury has to do it explicitly, as seed funding, because nothing else will.
Commerce clusters around taxi ranks, high streets and shopping nodes; members are spread across residential areas. So the two rules produce very different distributions of community funding across the same network, even with identical total volume.
Illustrative model showing shape, not measured data. Five communities on one network with equal total transaction volume under both rules. Community A is the trading hub; communities D and E are residential with few merchants.
| Community | Option A, buyer | Option B, merchant |
|---|
Neither distribution is automatically right. If the community fund is a development instrument for the areas members live in, the even spread is the point. If it is meant to reward whoever builds a trading hub, the concentration is the point. What we should not do is pick one and be surprised by the distribution it produces.
This table is not a tally and the count is not the verdict. Buyer-side wins more rows, but only because I happened to write more rows of the kind it wins; a different but equally fair criteria list would produce a different count. The materiality column is my judgement, offered so it can be argued with rather than inherited.
| Criterion | Why it matters | Materiality | Stronger option |
|---|---|---|---|
| Funding a new community | Decides whether a community launch is viable without a subsidy | High | Buyer |
| Pays for merchant acquisition | Merchant density is the binding constraint on member value and retention | High | Merchant |
| Income matches liabilities | Campaigns pay members, so a member-denominated income base self-balances | High | Buyer |
| Alignment with spend anywhere | Openness only survives if operators benefit from outsiders shopping locally | Medium | Merchant |
| Resists concentration | A compounding hub advantage has no natural check once it starts | Medium | Buyer |
| Pays for member acquisition | Onboarding, KYC, education and support are the expensive, unglamorous work | Medium | Buyer |
| Resists rate arbitrage | If communities set their own rates, the priced side gets shopped around | Medium | Buyer |
| Cost of multi-community membership | A governance cost rather than a money one; whichever side carries the money needs a single answer | Low | Merchant |
| Fraud and gaming surface | Round-tripping is unprofitable under both, since the slice comes out of merchant gross | Low | Neither |
The case against reading this as a buyer-side win: merchant acquisition is the one criterion that threatens the platform's core promise rather than its growth rate. A community that cannot fund its launch is a slow expansion problem. A network where nobody is paid to recruit merchants produces members with nowhere to spend, and those members churn. If that single criterion is judged to dominate, it outweighs the rows on the other side and the recommendation below should be rejected in favour of a community-level merchant slice.
The configured retail structure pays a 5% rebate to the buyer, 7.5% to the buyer's direct referrer, and 2.5% to the community treasury. Total commission is 15% of gross and the merchant nets 85%.
Two things about that structure are worth noting, because they bear on the decision. Retail declares no second or third referral level, so the unresolved-referral backstop cannot fire on a retail sale; the treasury's retail income is the 2.5% slice and nothing else. And the airtime structure declares no community slice at all, so airtime contributes to the treasury only through the backstop, above a R500 minimum.
At 2.5%, the community fund scales as follows.
| Monthly retail volume from the community's members | Fund at 2.5% | If split evenly, 1.25% |
|---|---|---|
| R50 000 | R1 250 | R625 |
| R100 000 | R2 500 | R1 250 |
| R250 000 | R6 250 | R3 125 |
| R500 000 | R12 500 | R6 250 |
| R1 000 000 | R25 000 | R12 500 |
| R2 000 000 | R50 000 | R25 000 |
The headline is the bottom row. A community needs roughly R2 million in monthly member retail volume to put R50 000 a month into its treasury. Split the slice evenly and it needs R4 million for the same result. That is the entire compromise question expressed as a number: not whether splitting is elegant, but whether a community can plausibly double its volume to stand still.
Rates read from the seeded retail structure. Because commission structures are version-controlled and can be overridden per merchant and per product, the live production rate should be confirmed before these figures are quoted.
Two slices, one following each side, is how mature payment networks do it; card interchange separates issuer-side and acquirer-side fees, each named to a party. It funds both public goods in proportion to contribution and removes both free-rider problems.
The cost lands in one of two places, and neither is comfortable:
Whether option 1 is survivable is arithmetic rather than judgement, and the section above does most of it: at the current 2.5% slice, splitting evenly means a community needs double the volume to hold its treasury steady. What remains is one measurement and one target, both named in the decision block below.
I am not in favour of moving the community slice to the merchant side, and I am not in favour of a straight split either. Rather something like this:
Keep the community treasury on the buyer's community, unchanged from the current ruling. It self-seeds new communities, its income matches the member campaigns it funds, and it keeps the rate out of reach of arbitrage.
Then add a separate merchant-side slice that accrues to Kiota rather than to a community, earmarked for merchant acquisition.
The reasoning is public goods matching: fund each good at the level at which it is actually public. Member welfare benefits one community, so a community fund financed by member spend is correct. Merchant density benefits every community equally, so it is a network utility and should be bought once, centrally, rather than competed over locally.
That buys the merchant-recruitment funding the buyer-side rule undersupplies, without importing any of the merchant-side damage: no compounding hub advantage, no inter-community undercutting, no cold-start trap, and no contested primary membership.
It does imply a division of labour we should say out loud: communities recruit members, the platform recruits merchants. If we would rather operators own merchant acquisition locally, then a community-level merchant slice is the right instrument and concentration is the price, in which case new communities need explicit seed funding from Kiota's treasury, because the model will not provide it.