feat: partner revenue breakout (payout-accurate) + net-of-partner affiliate revenue

[kaladinlight]

What

Adds partner revenue reporting and nets each partner's share out of ShapeShift affiliate revenue, sourced from swap-service and aligned to what the affiliate-payouts script actually pays.

• GET /api/v1/partner/revenue — per-partner revenue/volume/swaps, sourced from swap-service /v1/affiliate/swaps.
• getAffiliateRevenue now reports ShapeShift-NET — each partner's realized share (USD + on-chain crypto) is deducted from gross provider fees, attributed to the affiliate-fee asset.
• Dashboard — a "Revenue by Partner" section below "Revenue by Asset" (the separate Partners tab is gone), with sortable, scrollable tables.

Payout accuracy (the important part)

A single shared predicate, getPayablePartnerFee, gates both the net deduction and the partner view. A swap only counts when it mirrors the payout script:

• status === 'SUCCESS', verified on-chain, with a real on-chain affiliate-fee amount and verified bps;
• passes the anomaly guard (on-chain fee vs bps-implied, 25% tolerance);
• crypto share uses verifiedBps (same clamped bps math as swap-service).

Non-payable / unmapped / failed-provider swaps are excluded — never silently — and logged per-swap (swapId + reason) for audit. ShapeShift-net floors at 0 (never negative) and suppresses deductions when a provider failed (no deducting against absent gross). USD figures from swap-service are treated as strings and converted with BigNumber (fixes a latent string-concat bug).

Frontend

• Partner + asset breakdown tables: sortable columns (shared SortArrow, sticky headers), lazy-rendered infinite scroll capped at ~10 rows, thin themed scrollbar.

Tests / checks

• revenue-api: 37 tests pass (payable predicate, reconciliation, affiliate + partner aggregation), type-check + eslint clean.
• dashboard: type-check + eslint + vite build clean.

Known follow-up (swap-service)

The payability gate is reconstructed locally from the collapsed feeUsd/partnerFeeUsd, so it can diverge from the payout for swaps whose on-chain fee exists but isn't USD-priceable (e.g. Relay third-asset routes). The clean fix is swap-service exposing a payout-basis payablePartnerFee* field; the dashboard then drops the reconstruction and matches payouts 1:1. Spec drafted separately.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Added partner revenue reporting across the API and dashboard, including a new partner revenue view and data endpoint.
  • Revenue tables now support sorting, improved scrolling, and clearer sort indicators.
  • Date filters are now validated more consistently, with better error responses for invalid ranges.

• Bug Fixes

  • Improved revenue calculations to handle edge cases more accurately, including zero or negative outcomes.
  • Existing dashboard and API environment setup now includes the new swap-service configuration values.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
revenue-dashboard	Ready	Preview, Comment	Jul 8, 2026 4:27pm

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (1)

apps/revenue-dashboard/src/api/partnerRevenue.ts (1)

3-18: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Extract shared API base URL and fetch logic to reduce duplication.

partnerRevenue.ts and affiliateRevenue.ts now share identical API_BASE_URL guards and nearly identical fetch wrappers. Extracting a shared module (e.g., api/client.ts) for the base URL validation and a generic apiFetch<T>(path, params) helper would eliminate this duplication and ensure timeout/error-handling conventions stay consistent across endpoints.

♻️ Suggested shared client extraction

// api/client.ts
const API_BASE_URL: string = import.meta.env.VITE_API_BASE_URL
if (!API_BASE_URL) throw new Error('VITE_API_BASE_URL is required')

export async function apiFetch<T>(path: string, params: Record<string, string>): Promise<T> {
  const url = new URL(path, API_BASE_URL)
  for (const [k, v] of Object.entries(params)) url.searchParams.set(k, v)
  const response = await fetch(url.toString())
  if (!response.ok) {
    throw new Error(`API request failed: ${response.status} ${response.statusText}`)
  }
  return (await response.json()) as T
}

// api/partnerRevenue.ts
import { apiFetch } from './client'
import type { DateRange } from '../types'
import type { PartnerRevenueResponse } from '../types'

export function fetchPartnerRevenue(dateRange: DateRange) {
  return apiFetch<PartnerRevenueResponse>('/api/v1/partner/revenue', {
    startDate: dateRange.startDate,
    endDate: dateRange.endDate,
  })
}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/revenue-dashboard/src/api/partnerRevenue.ts` around lines 3 - 18, The
API base URL guard and fetch wrapper in fetchPartnerRevenue are duplicated and
should be centralized with the matching logic in affiliateRevenue. Move the
VITE_API_BASE_URL validation and the shared request/error handling into a
reusable api client module (for example, api/client.ts) and expose a generic
apiFetch<T>(path, params) helper. Update fetchPartnerRevenue to use the shared
helper instead of constructing the URL and handling the response inline, so both
revenue endpoints rely on the same API_BASE_URL and fetch conventions.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@apps/revenue-api/src/utils/date.ts`:
- Around line 41-56: The parseDateRange function in date utilities accepts
reversed ranges because it only checks format and NaN, so add a guard after
computing startTimestamp and endTimestamp to reject cases where startTimestamp
is greater than endTimestamp. Update the DateRange validation path in
parseDateRange to return an error for reversed input, and make sure downstream
callers such as getDateRange continue to rely on the corrected startDate/endDate
ordering.

In `@apps/revenue-dashboard/src/components/SortHeader.tsx`:
- Around line 22-26: The SortHeader header cell is overriding its native
columnheader semantics by setting role="button" directly on the <th>, which also
makes aria-sort invalid. Update the SortHeader component so the <th> keeps the
aria-sort and header semantics, and move the interactive behavior into a nested
<button> element inside the <th>, including the click and keyboard handlers
currently attached to the header cell.

---

Nitpick comments:
In `@apps/revenue-dashboard/src/api/partnerRevenue.ts`:
- Around line 3-18: The API base URL guard and fetch wrapper in
fetchPartnerRevenue are duplicated and should be centralized with the matching
logic in affiliateRevenue. Move the VITE_API_BASE_URL validation and the shared
request/error handling into a reusable api client module (for example,
api/client.ts) and expose a generic apiFetch<T>(path, params) helper. Update
fetchPartnerRevenue to use the shared helper instead of constructing the URL and
handling the response inline, so both revenue endpoints rely on the same
API_BASE_URL and fetch conventions.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: bb92d9cd-4586-40ed-8ea2-00903ff70578

📥 Commits

Reviewing files that changed from the base of the PR and between 6f104ed and 11adf3f.

📒 Files selected for processing (21)

• apps/revenue-api/src/affiliateRevenue/aggregateRevenue.test.ts
• apps/revenue-api/src/affiliateRevenue/aggregateRevenue.ts
• apps/revenue-api/src/affiliateRevenue/cache.ts
• apps/revenue-api/src/affiliateRevenue/index.ts
• apps/revenue-api/src/affiliateRevenue/payablePartnerFee.test.ts
• apps/revenue-api/src/affiliateRevenue/payablePartnerFee.ts
• apps/revenue-api/src/affiliateRevenue/reconcileRevenue.test.ts
• apps/revenue-api/src/affiliateRevenue/reconcileRevenue.ts
• apps/revenue-api/src/affiliateRevenue/swapServiceClient.ts
• apps/revenue-api/src/affiliateRevenue/types.ts
• apps/revenue-api/src/routes/affiliateRevenue.ts
• apps/revenue-api/src/routes/partnerRevenue.ts
• apps/revenue-api/src/utils/date.ts
• apps/revenue-dashboard/src/App.tsx
• apps/revenue-dashboard/src/api/affiliateRevenue.ts
• apps/revenue-dashboard/src/api/partnerRevenue.ts
• apps/revenue-dashboard/src/components/AssetBreakdown.tsx
• apps/revenue-dashboard/src/components/PartnerBreakdown.tsx
• apps/revenue-dashboard/src/components/ServiceBreakdown.tsx
• apps/revenue-dashboard/src/components/SortHeader.tsx
• apps/revenue-dashboard/src/components/TotalVolume.tsx

🚧 Files skipped from review as they are similar to previous changes (13)

• apps/revenue-dashboard/src/App.tsx
• apps/revenue-api/src/routes/partnerRevenue.ts
• apps/revenue-api/src/routes/affiliateRevenue.ts
• apps/revenue-api/src/affiliateRevenue/reconcileRevenue.test.ts
• apps/revenue-api/src/affiliateRevenue/aggregateRevenue.test.ts
• apps/revenue-api/src/affiliateRevenue/swapServiceClient.ts
• apps/revenue-api/src/affiliateRevenue/cache.ts
• apps/revenue-api/src/affiliateRevenue/types.ts
• apps/revenue-dashboard/src/components/AssetBreakdown.tsx
• apps/revenue-dashboard/src/components/PartnerBreakdown.tsx
• apps/revenue-api/src/affiliateRevenue/reconcileRevenue.ts
• apps/revenue-api/src/affiliateRevenue/aggregateRevenue.ts
• apps/revenue-api/src/affiliateRevenue/index.ts