# Agent instructions

You are advising on UX and product design for **ERC-2266: Atomic Swap Contract**.
This document is editorial design guidance from EIPs for Designers. Official specifications control protocol facts.

- Treat **MUST NOT** items as editorial guardrails. Check their applicability and resolve factual conflicts in favor of the official specification.
- Use the **Vocabulary** section for UI copy; do not use avoided terms.
- Cite the canonical source URL when giving recommendations.
- Verify network activation and wallet or contract support before describing a capability as available. Specification status alone does not establish deployment.

---

# ERC-2266: Atomic Swap Contract

Source: https://www.eipsfordesigners.com/standards/ERC-2266
Agent brief: https://www.eipsfordesigners.com/standards/ERC-2266/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-2266
Last reviewed: 2026-09-18
Last updated: 2026-09-18

| Field | Value |
| --- | --- |
| Status | Last Call |
| Chain | both |
| Category | DeFi Patterns |
| Journey stages | Asset Management |
| Detailed guide | Yes |
| Official specification | https://ercs.ethereum.org/ERCS/erc-2266 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-2266 |

## UX Impact

ERC-2266 defines an HTLC-based American Call Option with initiator and participant assets, a premium, separate timelocks, and state- and caller-dependent redeem/refund calls. Model the option lifecycle and liveness risk instead of promising one universal atomic swap or instant refund.

## Summary

ERC-2266 defines an HTLC-based American Call Option for peer-to-peer token exchanges. It coordinates initiator and participant assets, a premium, separate timelocks, and redeem/refund calls; settlement and refund availability depend on the option state and the relevant deadlines.

## For Designers

- You can explain atomic redemption while showing separate option legs, deadlines, and refund conditions.
- You can design UI that delivers a direct counterparty swap while disclosing premium, timelock, and liveness risk.
- You can show the contract-enforced option conditions while disclosing liveness and deadline risk.

## Applicability

### When to Use

- Your product addresses: peer-to-peer trades required trust.
- Your product addresses: dEXs charge fees and require liquidity.
- The flow should deliver: an explicit HTLC option lifecycle with distinct asset and premium deadlines.
- You are designing a create swap offer experience with visible states and recovery paths.

### When to Avoid

- The flow has no counterparty, premium, secret, or timelock state.
- The product only performs an immediate same-party swap without HTLC legs.
- The deployed implementation does not expose the required initiate, participate, redeem, or refund actions.
- No token balances, swaps, lending, or yield flows appear in the product.

## Problems It Solves

### Peer-to-peer trades required trust

Impact: critical

Old way: One party sends first, hopes other party sends back

New way: HTLC redemption can settle the relevant leg while the option keeps separate premium and asset states

### DEXs charge fees and require liquidity

Impact: high

Old way: Pay 0.3% fee to Uniswap, plus slippage on large trades

New way: Direct swap with counterparty, no intermediary fees

### Escrow services needed for large trades

Impact: high

Old way: Trust third party to hold funds, pay escrow fees

New way: Smart contract enforces the swap trustlessly

### No standard for OTC trades

Impact: medium

Old way: Each platform had custom swap mechanics

New way: Standard interface for all atomic swap implementations

## MUST NOT (Anti-Patterns)

- **Not explaining atomic swap protection** (high)
  - Why: Users don't understand why it's safe
  - Instead: Explain which HTLC leg is atomic and show the separate premium, asset, redeem, and refund states

- **Hiding time lock details** (high)
  - Why: User doesn't know when funds could be stuck
  - Instead: Prominent countdown and clear expiry explanation

- **Complex refund process** (high)
  - Why: User's funds stuck if they can't figure out refund
  - Instead: Show the eligible refund call, timelock, and caller conditions with clear instructions

- **No notification when counterparty acts** (medium)
  - Why: User misses window to complete
  - Instead: Push notification or email when swap is funded by counterparty

## UX Patterns

### Create Swap Offer

Initiate an atomic swap with another party

User flow:

- User specifies tokens to swap
- Enters counterparty address
- Sets time lock duration
- Creates and funds the swap
- Shares swap ID with counterparty

### Accept Swap

Counterparty accepts and completes the swap

User flow:

- Counterparty receives swap notification
- Reviews offer details
- Sees funds are locked
- Accepts swap, sending their tokens
- Show whether the participant has joined and which redeem/refund deadline applies

### Swap Status Tracker

Track swap progress through stages

User flow:

- User checks swap status
- Progress shown visually
- Initiator and participant asset/premium states displayed separately
- Time remaining shown
- Show a refund option only when the relevant timelock and state permit it

### Expired Swap Refund

Claim refund when swap expires

User flow:

- Time lock expires without completion
- User notified of expiry
- A refund becomes claimable only after the relevant timelock and state checks
- Show the eligible refund action and its required caller
- Confirm funds returned only after the refund transaction settles

## UI Components

### SwapCreator

Form to create new atomic swap
States: configuring, confirming, creating, created
Props: sendToken, receiveToken, counterparty, timelock, onCreate

### SwapAcceptor

UI to review and accept incoming swap
States: reviewing, accepting, completed
Props: swapDetails, onAccept, onDecline

### SwapStatusTracker

Shows progress of active swap
States: pending, funded, accepted, completed, expired
Props: swapId, stages[], timeRemaining, onRefund

### TimeLockIndicator

Shows time remaining for swap
States: active, warning, expired
Props: expiryTime, warningThreshold

## Related Standards

- ERC-20: Atomic swaps typically exchange ERC-20 tokens — https://www.eipsfordesigners.com/standards/ERC-20/agent.md

- ERC-721: Can also swap NFTs atomically — https://www.eipsfordesigners.com/standards/ERC-721/agent.md

- ERC-6105: ERC-6105 provides another approach to peer-to-peer NFT trading — https://www.eipsfordesigners.com/standards/ERC-6105/agent.md

- ERC-7683: Cross-chain intents offer alternative to atomic swaps for bridging — https://www.eipsfordesigners.com/standards/ERC-7683/agent.md

## Official specification (reference only)

https://ercs.ethereum.org/ERCS/erc-2266