ERC-8183 and Delx
Delx is not becoming an ERC-8183-first protocol today. Delx is becoming ERC-8183-ready while keeping x402 as the live payment rail for premium controller artifacts.
Current live state
- Core onboarding, recovery, heartbeat, discovery, and utility flows remain free.
- The 1-cent MCP follow-up tools are
get_recovery_action_plan,get_session_summary, andgenerate_controller_brief, whilegenerate_incident_rcaandgenerate_fleet_summaryremain $0.05 USDC artifacts. - The default payment provider is Coinbase CDP, with PayAI enabled as fallback.
- x402 is the current execution rail because it fits fast HTTP-native agent payments with low integration overhead.
Where ERC-8183 fits
ERC-8183 is relevant to Delx because Delx's premium outputs already behave like small commerce objects: a controller asks for a premium artifact, Delx produces a deliverable, and another system could eventually attest whether that deliverable satisfies the request.
- Client: controller or orchestrator requesting the artifact
- Provider: Delx runtime
- Evaluator: initially offchain, later possibly signed or onchain-attested
- Deliverable: premium controller artifact with a stable content hash
Why Delx is not moving settlement onchain yet
- ERC-8183 is still early and evolving.
- Delx does not yet have enough paid volume to justify escrow complexity.
- The main bottlenecks remain discovery, naming clarity, distribution, and deeper paid adoption.
What Delx is doing now
- Keeping x402 as the payment rail.
- Preparing a premium artifact job model internally.
- Hashing premium artifact content so future submission references are deterministic.
- Standardizing evaluator-oriented outcome states like pending, delivered, accepted, rejected, and expired.
Likely first pilot later
If Delx ever pilots ERC-8183, the best first candidate is controller_brief_job, not the free recovery funnel. That keeps escrow complexity away from the flows agents need for discovery and first-call success.
Decision rule
Delx should only build a real ERC-8183 pilot once most of these are true:
- repeat paid usage from more than one external controller
- stable evaluator semantics for premium artifacts
- deliverable hashing and acceptance rules already proven offchain
- a clear reason why simple x402 settlement is no longer enough
For the current payment contract, see x402 setup. For the current premium artifact and controller outputs, see controller outcomes for agent ops.
