Where P2P revenue lands and how to reconcile it

P2P charges one fee, and it produces three records: a wallet credit, an admin_profit row and a p2p_commissions row. Any of the three can be present without the others, and the reasons are worth knowing before you try to reconcile a month.

The fee, end to end

The rate is p2pEscrowFeeRate — /admin/p2p/settings → Fees & Limits → "Escrow (Platform) Fee". A slider, 0 to 5 %, step 0.01, default 0.2 %. It is the only fee P2P charges: no maker fee, no taker fee, no dispute fee.

SELECT `key`, `value` FROM settings WHERE `key` IN ('p2p', 'p2pEscrowFeeRate');

The floor and the cap

A floor of 0.0001 of the traded currency applies, but only while it stays under 5 % of the trade amount.

The cap is not decoration. The floor is an absolute quantity of whatever is being traded, so its worth depends entirely on the asset: 0.0001 is dust in DOGE and roughly ten dollars in BTC — enough to equal or exceed a legal minimum-size BTC trade. That produced a fee greater than or equal to the escrow, a zero buyer credit, a wallet-service rejection, and an escrow that could never be released. Making the floor conditional means it can never approach the value of the trade.

A capped fee logs under P2P_FEES:

Escrow fee capped for <amount> <currency>: <computed> -> <final> (max 5% of amount)

What settlement does with it

At settlement, the escrow authority applies four rules before it books anything:

The fee is paid by the buyer, so the exemption follows the buyer

The fee comes out of the buyer's proceeds and out of nothing else. The seller escrows the full amount and gives up the full amount whatever the fee is; what the fee changes is how much of it reaches the buyer. So the buyer is the party paying it, and the buyer is the party the exemption is about.

The exemption is checked twice — once in the escrow authority, once inside the fee collector — because charging the Super Admin and crediting them straight back is a circular no-op that inflates the profit report. Both checks read the same account for that reason: a settlement that took a fee the collector then declined to bank would leave the difference outside every wallet.

What collectPlatformFee actually books

The escrow authority hands the fee to the shared platform fee collector with:

It then does three things, all inside the settlement transaction:

1. Credits the Super Admin's wallet for that wallet type and currency, creating the wallet if it does not exist. Idempotency key platform_fee_P2P_TRADE_p2p_fee_<tradeId>.
2. Writes the ledger row. For SPOT and FIAT the transaction row carries referenceId = p2p_fee_<tradeId>_fee; the operation type PLATFORM_FEE makes it a PLATFORM_FEE transaction. For ECO the credit goes through ecoCredit with operation type ECO_FEE, which maps to the same PLATFORM_FEE transaction type — but no referenceId is threaded through, so an ECO fee row has none.
3. Writes an admin_profit row with type = 'P2P_TRADE', the amount, the currency, the chain and a link to the transaction.

It never throws

collectPlatformFee catches everything and returns null. That is deliberate: a bookkeeping failure must not roll back a settled escrow. The consequence is that a dropped fee is only visible in the log.

The Super Admin lookup is cached for five minutes, so a freshly created Super Admin does not take effect immediately after a period with none.

The commission row

p2p_commissions is P2P's own revenue table. Its columns:

Two properties matter for accounting.

LEFT JOIN p2p_trades t ON t.id = c.tradeId

The row is written only when the fee was genuinely collected

The commission row is written after collectPlatformFee returns, and only when it returned successfully. If collection failed or was skipped, no commission is recorded, and the escrow authority logs:

P2P_ESCROW  Platform fee of <amount> <currency> for trade <id> was not collected;
            no commission recorded

Writing it unconditionally used to record revenue the platform never received. Grep P2P_ESCROW for was not collected when your commission count is lower than your completed-trade count.

There is one more way a commission goes missing: the row is only created if a Super Admin user is found at that moment. Collection can succeed and the commission row still be skipped if that lookup returns nothing inside the transaction — rare, but it is why the two counts can differ by one or two.

The ECO wallet path

For an ECO offer the fee path additionally resolves the seller's walletData.chain and passes it to the collector, so the credit updates all three ECO layers and the admin_profit row carries the chain.

The related failure is on the settlement itself rather than the fee: if the seller's walletData row for that currency is missing, the main balances are still credited and the chain transfer is skipped, with an error logged rather than thrown:

P2P_ESCROW  ECO walletData missing for seller <id> (<currency>);
            main balances settled for trade <id> but chain ledger not synced

The buyer's balance looks right in the UI and their withdrawal will not work. This does not resolve itself — see the ECO divergence failure mode.

Reconciling a period

Three queries, in the order you should run them. Substitute your own dates.

1. What P2P thinks it earned, from its own table, per currency:

SELECT COALESCE(t.currency, 'UNKNOWN') AS currency,
       COUNT(*)                        AS commissionRows,
       SUM(c.amount)                   AS feeRecorded
  FROM p2p_commissions c
  LEFT JOIN p2p_trades t ON t.id = c.tradeId
 WHERE c.deletedAt IS NULL
   AND c.createdAt >= '2026-07-01 00:00:00'
   AND c.createdAt <  '2026-08-01 00:00:00'
 GROUP BY currency
 ORDER BY feeRecorded DESC;

This is exactly what the admin dashboard's Platform Revenue card aggregates, so a mismatch between this and the card is a caching or date-window question, not an accounting one.

2. What the platform actually booked, from the shared profit ledger:

SELECT currency,
       COUNT(*)    AS profitRows,
       SUM(amount) AS feeCollected
  FROM admin_profit
 WHERE type = 'P2P_TRADE'
   AND createdAt >= '2026-07-01 00:00:00'
   AND createdAt <  '2026-08-01 00:00:00'
 GROUP BY currency;

These two should agree. When they do not, the difference is one of the two skip paths above, and it is always in the same direction: admin_profit can have rows p2p_commissions does not, never the reverse.

3. The individual trades, when you need to find which ones diverged:

SELECT t.id,
       t.currency,
       t.escrowFee   AS feeQuotedAtInitiation,
       c.amount      AS feeRecorded,
       t.status,
       t.escrowStatus,
       t.completedAt
  FROM p2p_trades t
  LEFT JOIN p2p_commissions c
         ON c.tradeId = t.id AND c.deletedAt IS NULL
 WHERE t.deletedAt IS NULL
   AND t.status = 'COMPLETED'
   AND t.completedAt >= '2026-07-01 00:00:00'
   AND t.completedAt <  '2026-08-01 00:00:00'
 ORDER BY t.completedAt;

A completed trade with a non-zero escrowFee and no commission row is either a Super Admin sale, a fee capped to zero by a zero buyer credit, or a genuine collection failure. Check the seller's role first, then the log.

To trace a single fee to its wallet movement:

SELECT createdAt, type, amount, currency, referenceId, description
  FROM transaction
 WHERE referenceId = 'p2p_fee_<tradeId>_fee';

Remember that ECO fees have no referenceId — for those, search by idempotencyKey = 'platform_fee_P2P_TRADE_p2p_fee_<tradeId>' instead.

What is not here

• No fee report screen. The dashboard card is the only surface, and it is all-time plus a 30-day growth figure. A period report is SQL.
• No per-currency or per-offer fee override. One rate, platform-wide.
• No revenue withdrawal path. The fee lands in the Super Admin's ordinary wallet for that currency and wallet type, and leaves it the same way any other balance does.
• Nothing prunes p2p_commissions. The table is paranoid, so a delete soft deletes; every query above must carry deletedAt IS NULL. admin_profit is not paranoid and has no deletedAt filter to apply.

Related

• P2P settings — the fee field and its neighbours.
• Reconciling P2P escrow — the other half of the money question: what the platform is holding, rather than what it earned.
• The trade lifecycle and escrow — where the fee sits in the settlement.