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.
Read down the criteria, not across the totals. The criteria are not equally weighted, and the weighting is a business call rather than an analytical one.
| Criterion | Why it matters | Stronger option |
|---|---|---|
| Funding a new community | Decides whether a community launch is viable without a subsidy | Buyer |
| Income matches liabilities | Campaigns pay members, so a member-denominated income base self-balances | Buyer |
| Pays for merchant acquisition | Merchant density is the binding constraint on member value and retention | Merchant |
| Pays for member acquisition | Onboarding, KYC, education and support are the expensive, unglamorous work | Buyer |
| Alignment with spend anywhere | Openness only survives if operators benefit from outsiders shopping locally | Merchant |
| Resists concentration | A compounding hub advantage has no natural check once it starts | Buyer |
| Resists rate arbitrage | If communities set their own rates, the priced side gets shopped around | Buyer |
| Cost of multi-community membership | Whichever side carries the money needs a single answer, so that side needs governance | Merchant |
| Fraud and gaming surface | Round-tripping is unprofitable under both, since the slice comes out of merchant gross | Neither |
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, not judgement, and we can settle it from Delft's actual volume. It turns on a number we have not written down yet.
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.