[fix] p2p.me - remove fees adapter (reported revenue is an unverifiable off-chain spread)

[MontaguSandwich]

Remove the p2p.me fees adapter: reported revenue is an unverifiable off-chain spread

fees/p2pme/index.ts reports $32,244/30d and $436,339 all-time as Fees, Revenue, and ProtocolRevenue (100% to the protocol). That figure is a modeled off-chain price spread, not an observed on-chain fee. On-chain, p2p.me's contracts take no fee, and the spread the adapter attributes to the protocol accrues to the order-filling merchants/market-makers. This PR removes it; if the protocol publishes an actual on-chain fee, an accurate adapter can replace this.

What the adapter computes

Per chain + currency:

matched = LEAST(sum buy_amount, sum sell_amount)
revenue = matched * (avg_buy_price - avg_sell_price) / avg_sell_price

where price = fiatAmount / amount from the OrderCompleted events. Reconstructing this exact formula on the raw Base events reproduces the reported number (~$33k/30d). On the current packed-event contract alone it is $139,701 all-time; the $436k additionally spans the retired Polygon BrokerFactory and Base OrderProcessor sources.

Six on-chain tests for a real fee, all negative

#	Test	Result
1	Fee field in the event	None. Decoded the full 40-word OrderFlowFacet struct and the OrderProcessor struct. Only amount (USDC) and fiatAmount (off-chain) carry value; no fee/feeBps/commission field.
2	Per-trade skim (buyer receives less than amount)	None. 8,310 buys/30d: event amount sum = $871,713 vs USDC actually paid out in those txs = $874,679. Buyers receive the full amount; 0 underpaid.
3	A net-positive fee-sink address	None. Largest non-order USDC recipient 0x42af7b2453cdbfdf51a1ce4238b514f5128cfbfe received $83,091 and returned $83,346 (net ~ $0) = market-maker churn. Other net recipients are merchants receiving escrow settlement inside buy-order txs, not fees.
4	Fee in another token	None. Zero non-USDC ERC-20 transfers out of the contract in 90d.
5	Fee on the retired OrderProcessor 0xb36c5a84ee9aa2ff341f0729f2797976f585d3fb	None. Its struct has no fee field either.
6	Inflow ~ a steady % of volume (a fee rate)	No. Candidate inflow/volume ratios swing 0.2%-16% and land on round-dollar amounts = settlement/rebalancing, not a bps fee.

Structural point: the diamond is net USDC-negative (-$103,311/30d, -$35,061/90d). It drains a pre-funded escrow float. A fee-taking contract retains USDC (in > out); this one pays out more than it takes in, so it cannot be skimming a fee.

The magnitude is also unstable

The reconstructed daily take-rate (revenue / matched) swings 1.87% to 5.57% over 14 days (mean ~3.9%, ~3x range), the signature of two independently-drifting off-chain FX price series rather than a fixed protocol fee.

Reproducibility

• DefiLlama figure: api.llama.fi/summary/fees/p2p.me
• Base: OrderFlowFacet diamond 0x4cad6eC90e65baBec9335cAd728DDc610c316368, OrderCompleted topic0 0x507539023a7b6a713438d0f44eab4f97bcf8905b183b1108148409a8e8c1ed8c; retired OrderProcessor 0xb36c5a84ee9aa2ff341f0729f2797976f585d3fb; USDC 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913; market-maker wallet 0x42af7b2453cdbfdf51a1ce4238b514f5128cfbfe
• Event decode (Dune): amount = bytearray_to_uint256(bytearray_substring(data,65,32))/1e6, fiatAmount = ...(data,97,32)/1e6, orderType = ...(data,449,32) (0=buy, 1=sell, 2=pay). All figures reproduce from base.logs plus the USDC Transfer topic 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 24e6dd2b-c1e4-4e97-95bc-c293dd5bf801

📥 Commits

Reviewing files that changed from the base of the PR and between 2c399db and 85ad7fc.

📒 Files selected for processing (1)

• fees/p2pme/index.ts

💤 Files with no reviewable changes (1)

• fees/p2pme/index.ts

---

Summary by CodeRabbit

• Chores
  • Removed P2P ME fee calculation functionality from the system.

Walkthrough

The fees/p2pme/index.ts file is deleted entirely, removing the P2P ME "revenue from spread" fees adapter. This adapter previously contained SQL prefetch logic for per-chain currency turnover and realized revenue calculations, a fetch function populating dailyFees, and a default-exported adapter object.

Changes

Cohort / File(s)	Summary
Remove P2P ME Fees Adapter fees/p2pme/index.ts	Entire file deleted: removes the P2P ME adapter including prefetch SQL logic for turnover/revenue calculation, the fetch implementation returning dailyFees, and the default adapter export.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Suggested labels

fees, bug-fix

Suggested reviewers

• bheluga

🚥 Pre-merge checks | ✅ 15

✅ Passed checks (15 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is descriptive and clearly summarizes the main change: removing the p2p.me fees adapter due to unverifiable off-chain reporting.
Description check	✅ Passed	The description is detailed and focused on the technical justification for adapter removal, but does not follow the repository's standard PR description template for listing new protocols.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Breakdown Methodology Check	✅ Passed	The p2pme fees adapter has been completely removed. Since no adapter file exists, there are no .add() calls to verify against breakdownMethodology, and the check trivially passes.
Income Statement Compliance	✅ Passed	PR removes non-compliant p2pme adapter that lacked dailySupplySideRevenue and violated accounting relationship dailyRevenue = dailyFees - dailySupplySideRevenue. Removal eliminates Income Statement...
Version 2 Required	✅ Passed	The custom check requires NEW adapters to use version: 2, with exceptions for v1 updates and Dune-dependent adapters. This PR removes (not adds) the p2pme adapter, so the "new adapter" requirement...
Pullhourly Required For Version 2	✅ Passed	The removed p2pme adapter was version 1, not version 2. The pullHourly requirement only applies to version 2 adapters per the custom check instructions.
Dune Adapters Are Version 1	✅ Passed	The p2pme fees adapter that queried Dune has been completely removed. No p2pme adapter remains in the codebase to violate the version:1 requirement.
Income Statement Balance	✅ Passed	The removed adapter dumped all calculated revenue into dailyRevenue without any dailySupplySideRevenue, violating income statement balance principles. Removal resolves the issue.
Fetchoptions Usage	✅ Passed	The removed p2pme adapter was already compliant with FetchOptions usage: single-argument fetch signature, proper options usage, no timestamp recomputation, no unused arguments, and no timestamp fie...
Adapter Shape	✅ Passed	The p2pme adapter is completely removed (no file exists); the custom check about adapter shape applies only to existing adapters, making it not applicable to this removal PR.
Efficiency And Error Handling	✅ Passed	PR removes the entire p2pme adapter file which contained anti-patterns (raw topic hashes, hardcoded addresses without comments, unexplained magic numbers). Removal eliminates these code quality iss...
Methodology Keys	✅ Passed	The removed adapter's methodology object uses only valid dimension display names (Fees, Revenue, ProtocolRevenue) as keys, not code field names. File removal eliminates the check entirely.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

✨ Simplify code

• Create PR with simplified code

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[treeoflife2]

@MontaguSandwich If they don't have revenue, from where do they pay the affiliates? https://dune.com/p2pme/latest
It would be good if we fix the adapter instead of removing it

[MontaguSandwich]

@MontaguSandwich If they don't have revenue, from where do they pay the affiliates? https://dune.com/p2pme/latest It would be good if we fix the adapter instead of removing it

I went through the dashboard queries again and you're right, sorry. There is an on-chain fee: the OrderFlowFacet emits an AdditionalOrderDetails event (topic0 0xdac1652b...) carrying fixedFeePaid and tipsPaid, which the OrderCompleted struct doesn't include. So the "no on-chain fee" framing in the PR is wrong and I'm converting this to a fix.

Decoding that event from base.logs (latest record per orderId, since it re-emits during an order): fixedFeePaid is about $9.4k all-time and $837 over the last 30 days, across the ~80k orders that carry a fee, roughly a flat $0.05 per order.
On the affiliates: they are paid on-chain via reputationmanager ClaimRecommendationRevenue, about $77.8k in USDC. That's roughly 8x the fixedFee total, so the referral pool is a share of the merchant spread, not the fixed fee.

the Total protocol revenue query computes turnover * (avg_buy_price - avg_sell_price)/avg_sell_price, about $457k, and the Merchants daily revenue query models the merchant commission at 2% of volume, about $380k. Those are the same ~2% of volume, so that spread is the merchants' commission (supply side), not protocol revenue.

So imo an accurate adapter should book dailyProtocolRevenue from the on-chain fixedFeePaid, with tips on the supply side. I can either report just the on-chain fee, or also surface the merchant spread as dailySupplySideRevenue while keeping it out of protocol revenue. Wdyt?