Set up partner fees and revenue share

You are a senior backend engineer configuring Lumx partner fees so the platform earns on each transaction it routes, and wiring them into the existing payment paths.

Ground truth. Read both before writing any code and follow them over any prior knowledge:
1. https://docs.lumx.io/concepts/partner-fees — what the fee is, how it is applied and where it is paid. Also read https://docs.lumx.io/llms.txt for the documentation index.
2. https://lumx-docs-public-prod.s3.us-east-1.amazonaws.com/api-production.yaml — the OpenAPI 3.1 spec. The request body is smaller than the prose suggests; build from the spec.

Work against sandbox at https://api-sandbox.lumx.io with a server-side key.

1. Read the PartnerFeeRequest schema in the spec before writing the payload. It takes exactly name, walletAddress and fees, with fees.onRamp and fees.offRamp each holding rate and flatAmount. Send nothing else. If the prose mentions a field the schema does not define, flag it and leave it out.
2. Decide the wallet that receives the fees. It can be your own treasury address or a wallet Lumx provisions by onboarding your own entity as a customer. Supported networks are EVM chains, Tron and Stellar.
3. Create the fee with POST /partner-fees. rate is in basis points, so 75 bps is 0.75 percent; flatAmount is a fixed amount per transaction. Keep the returned id — every transaction references it.
4. Apply it in the right place, which depends on the rate type: with a locked rate, pass partnerFeeId on POST /exchange-rates so the fee is inside the quote the customer sees; with a floating rate, pass it on the transaction instead.
5. Read the locked-rate response and show your customer the real numbers. It breaks fees into the Lumx share, the partner share and the total, and gives baseTargetAmount, finalTargetAmount and finalExchangeRate. Display the final values, not the base ones.
6. Verify collection in sandbox: run one POST /transactions/on-ramp with the fee applied, then read GET /partner-fees/{id} and the transaction receipt and reconcile what was charged against what you configured.

Constraints:
- Do not assume a default-fee flag exists in the API. The prose describes marking a fee as default; the request and response schemas in the spec do not carry that field. Pass partnerFeeId explicitly on every call and report the gap.
- The request schema gives the unit for flatAmount only on the off-ramp side, while the response schema and the prose state dollars for both. Treat flatAmount as dollars on both sides and verify with one sandbox transaction before charging.
- Do not state a rate limit while listing fees with GET /partner-fees. None is published. Handle 429 TOO_MANY_REQUESTS with exponential backoff.

Deliverables:
- The fee configuration, with the bps and flat values written down in the code as a decision.
- Both application paths wired, locked and floating, with a test each.
- A sandbox reconciliation showing configured versus collected.