How it works?

xEcho Facilitator uses an ERC-3009 relay proxy contract to enable on-chain settlement callbacks.

It first calls the USDC contract to complete the payment, and if the receiver implements the ISettler interface, it triggers its settlement callback function.

Core Concepts

1) Facilitator Onchain Settlement Proxy

Facilitator Onchain Settlement Proxy is a minimal forwarding proxy whose sole purpose is to ensure that after a successful USDC transfer, it checks whether the receiver is an ISettler contract. If so, it invokes the settlementCallback function to guarantee that both usdc.transferWithAuthorization and settler.settlementCallback execute atomically.

contract FacilitatorSettlementProxy {
    function transferWithAuthorization(
        address from,
        address to,
        uint256 value,
        uint256 validAfter,
        uint256 validBefore,
        bytes32 nonce,
        bytes calldata signature
    ) external {
        // make USDC transfer first
        usdc.transferWithAuthorization(from, to, value, validAfter, validBefore, nonce, signature);
        // and then call settlement callback if needed
        if (_isISettler(to)) {
            ISettler(to).settlementCallback(from, value, nonce);
        }
    }
}

This design does not modify the x402 protocol.

• Original settle flow:
  The Facilitator, after receiving the payer's Authorization, signs a calldata transaction invoking erc3009.transferWithAuthorization. The to address points to the USDC contract to complete the payment.
• New flow:
  The Facilitator signs the same calldata but replaces the to address with the FacilitatorSettlementProxy contract. The proxy then forwards the call to the USDC contract.

2) ISettler

ISettler is the payee's receiving contract. It accepts funds from the payer and performs predefined post-payment handling. It must implement the following interfaces:

interface ISettler is IERC165 {
    function settlementCallback(
        address payer,
        uint256 amount,
        bytes32 nonce
    ) external;

    function payoutUnsettledFunds(
        address token,
        uint256 amount
    ) external returns (bool success);
}

• settlementCallback is invoked by the FacilitatorSettlementProxy. When called, it indicates an incoming payment that requires settlement logic. If this function reverts, the payment is rejected.
• payoutUnsettledFunds is invoked by the payer. Because the payer's Authorization may be submitted directly to the USDC contract (bypassing the proxy), such funds skip settlementCallback and should be treated as invalid payments. The payer can reclaim these funds by calling payoutUnsettledFunds, which helps resolve payment disputes.

Integration with xEcho Facilitator

1. Implement the ISettler contract interface and define custom settlement logic.
2. Use the ISettler contract as the payee address and configure xEcho Facilitator to verify and settle payments.
3. xEcho Facilitator automatically triggers the on-chain settlement callback.

Developer docs will be available soon.

Use Cases

1) ISettler for Pay-to-Mint & Pay-to-Earn

Similar to cashback or reward systems in traditional payments, the payee can create an ISettler supporting Pay-to-Earn mechanics.

Pay-to-Mint implementation:

• Mint phase: the first 1,000 payments are held in the Settler contract while the payer mints incentive tokens defined by the payee.
• Launch phase: the Settler uses part of the funds and reward tokens to provide liquidity on Uniswap for a fair launch.
• Earn phase: subsequent payments send funds directly to the payee, while payers continuously share remaining incentive tokens.

2) ISettler for Result-Based Payments

When an AI Agent provides services, results may not always fully satisfy the payer. In existing models, the payer must "pay first, then receive," which lacks quality assurance.

By combining ERC-8004 (reputation & verification system) with ISettler, an A2A self-negotiated result-based payment model becomes possible.

Logic flow:

• Payment: funds remain locked within the Settler contract.
• Payer submits result: if accepted during the settlement window, the funds are paid out to the payee.
• Payer disputes result: disputes can be raised and resolved by an arbitrator to determine fund allocation.
• Post-dispute period: if no dispute, the payee can withdraw the funds.

On-Chain Settlement Callbacks Unlock Token Economics

Smart contracts are meant to express programmable tokenomics. However, in the current x402 payment flow, no smart contracts are involved — payments are direct peer-to-peer transfers, limiting composability.

On-chain settlement callbacks reintroduce programmability into x402 payments. They bring DeFi-like logic back into the payment layer — enabling any conceivable "payment-as-DeFi" model to emerge and evolve continuously.