Payment platforms need three things crypto rails rarely deliver: predictable settlement, multi-asset acceptance, and a compliance story. Eco’s vault model and dual-mode execution were designed around these constraints.Documentation Index
Fetch the complete documentation index at: https://eco.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
The pain you’re solving
- Customers want to pay with the stablecoin they already hold; you only want to receive USDC on Polygon
- Bridge failures in the middle of a payment flow create unrecoverable customer-service incidents
- Invoice flows need a static destination address that doesn’t change per payment
- Compliance team needs address screening + AML before funds settle
What Eco gives you
| Capability | Product |
|---|---|
| Accept any stablecoin, settle to one | Routes RFQ |
| Static address per invoice / per customer | Programmable Addresses |
| Gasless funding (no gas-token UX) | Funding methods — ERC-3009, Permit |
| Atomic refunds on failure | Vault model |
| Compliance at solver-selection layer | Solver allowlisting via Orchestration |
| Predictable settlement under solver outage | Settlement vs Orchestration |
Recommended product mix
| Use case | Use |
|---|---|
| Per-invoice deposit address | Programmable Addresses |
| Cross-chain settlement | Routes API |
| Gasless customer payment | ERC-3009 → Routes via Gateway Fast Deposits pattern |
| Multi-currency acceptance | Stable RFQ |
Patterns
Customer pays an invoice with any stable
Generate a Programmable Address per invoice, derived from(merchantAddress, invoiceId). Show the address to the customer. Customer transfers (or signs ERC-3009 for gasless). The address publishes an intent that delivers the merchant’s preferred stablecoin on the merchant’s preferred chain.
→ Recipe: Gasless USDC into Gateway