# ERC-5528: Refundable Fungible Token

Source: https://www.eipsfordesigners.com/standards/ERC-5528
Agent brief: https://www.eipsfordesigners.com/standards/ERC-5528/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-5528
Last reviewed: 2026-05-25
Last updated: 2026-05-25

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Security & Trust |
| Journey stages | Asset Management |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/erc-5528 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-5528 |

## UX Impact

Token sales use escrow with built-in refund mechanism — funds locked until conditions met, buyers protected from rugpulls. Design implications: show escrow status (Funded/Running/Success/Failed), display refund eligibility, visualize lock period timeline. Design decisions: how much escrow complexity to expose — show full state machine or simplified status, balance transparency with cognitive load.

## Summary

Token sales use escrow with built-in refund mechanism — funds locked until conditions met, buyers protected from rugpulls.

## For Designers

- You can show escrow status as a simple progress bar: Funded → Running → Success or Refund.
- Your contributor view can display locked amount with expected release or refund date.
- You can explain failed sales with a clear Your refund is available CTA instead of raw revert text.

## Applicability

### When to Use

- Token launches use on-chain escrow with conditional release.
- Buyers need protection when sale outcome is uncertain.
- Your UI surfaces crowd-sale or IDO participation.

### When to Avoid

- Direct swap or AMM purchases with no escrow phase.
- Sale contracts do not implement ERC-5528.
- Users only hold tokens post-settlement with no escrow period.

## Problems It Solves

### Token sale rug pulls

Impact: critical

Old way: Funds sent directly to team wallet with no recourse

New way: Escrow holds funds until verifiable success conditions

### Users think contributed ETH disappeared

Impact: high

Old way: Wallet shows lower balance with no explanation

New way: Escrowed amount labeled with status and release path

### Failed launches leave contributors stranded

Impact: high

Old way: Manual refunds or social pressure on team

New way: Automatic on-chain refund path when sale fails

## Anti-Patterns

### Showing zero balance with no escrow explanation

Severity: critical

Users assume funds were stolen

Instead: Separate Escrowed row with status and amount

### Hiding failed state behind generic transaction error

Severity: critical

Contributors cannot find refund path

Instead: Dedicated Failed sale screen with Claim refund

### Exposing raw state enum names (FUNDED, RUNNING)

Severity: high

Protocol jargon erodes trust

Instead: Human labels: Sale open, Processing, Complete, Refunded

## Design Decisions

### How much escrow complexity to expose?

Recommendation: Show simplified four-state timeline; tuck contract addresses behind advanced.

Rationale: Contributors need confidence, not Solidity architecture.

### Should locked funds appear in wallet balance?

Recommendation: Show separate Escrowed line item, not merged with spendable balance.

Rationale: Merged balances cause panic sends and support tickets.

### How to communicate failed sales?

Recommendation: Lead with You get a full refund, then explain why the sale failed.

Rationale: Money-back clarity reduces FUD faster than technical reasons.

## States to Design

### Escrow funded — sale open

Trigger: User contributed; sale still accepting.

User need: Know funds are locked but safe.

Design response: Show locked amount with Running status and sale end time.

### Awaiting outcome

Trigger: Sale closed; settlement pending.

User need: Understand nothing is lost during processing.

Design response: Processing status with expected resolution window.

### Success — tokens received

Trigger: Sale succeeded.

User need: See tokens and closed escrow.

Design response: Success card with token balance and escrow released note.

### Failed — refund available

Trigger: Sale failed conditions.

User need: Get money back quickly and clearly.

Design response: Failed badge with Claim refund CTA and full amount.

### Refund claimed

Trigger: User reclaimed escrow.

User need: Confirm funds returned.

Design response: Completed refund receipt with amount and timestamp.

## Vocabulary

- Use "Funds held safely" instead of "Locked in escrow contract": Reassurance over smart-contract vocabulary.

- Use "Claim your refund" instead of "Trigger refund()": Action-oriented commerce language.

- Use "Sale succeeded" instead of "State SUCCESS": Outcome language, not enum values.

## What to Prototype First

### Sale escrow dashboard

Contributors check status repeatedly during a live sale.

Covers: Funded, Running, Cap reached

- Status pill
- Locked amount
- Timeline
- Your contribution row

### Failed sale refund

The refund moment is when trust is won or lost.

Covers: Failed state, Refund available, Refund claimed

- Plain-language failure reason
- Claim refund CTA
- Amount returned

### Successful settlement

Users must see tokens received and escrow released.

Covers: Success, Token delivery, Escrow closed

- Tokens received summary
- Escrow released badge
- Explorer link

### Contribution during lock

New buyers need to understand funds are not immediately spendable.

Covers: Active lock, Cannot withdraw early

- Funds held securely copy
- Release conditions
- No panic empty-wallet state

## Mental Model

### Contribution

User sends funds into escrow — they do not own tokens yet, they own a claim.

### Escrow lock

Funds stay in the contract until success conditions or failure triggers refund.

### Success path

Sale completes → tokens mint or transfer → escrow releases to project.

### Failure path

Conditions unmet → contributors reclaim full contribution from escrow.

### State machine

Funded, Running, Success, Failed are user-visible milestones, not internal enum names.

## Seen in the Wild

- CoinList: Token sale escrow patterns set user expectations for locked contributions. (https://coinlist.co/)

- Fjord Foundry: Fair launch interfaces show contribution and settlement states. (https://fjordfoundry.com/)

- ENS App: Commit-reveal and escrow-adjacent deposit patterns inform timeline UX. (https://app.ens.domains/)

- Gitcoin: Quadratic funding rounds use similar held-funds mental models. (https://gitcoin.co/)

## On Monad

### Settlement speed

Ethereum: Escrow resolution may take multiple blocks

Monad: Fast finality tightens feedback after sale closes

Design implication: Prefer inline status updates over long polling modals.

### Contribution cost

Ethereum: Gas may deter small contributions

Monad: Lower fees enable broader participation tiers

Design implication: Show micro-contribution options without gas warnings.

## UX Patterns

### Escrow Status Timeline

Visual Funded → Running → Success/Failed progression.

Components: StatusTimeline, ContributionCard, LockAmount

User flow:

- User contributes
- Timeline updates
- Outcome resolves
- Tokens or refund shown

Mockup registry key: `concept/verify-safety` (React UI on the live standard page).

### Claim Refund Flow

One-tap refund when sale fails.

Components: FailedBanner, RefundCTA, ReceiptModal

User flow:

- Sale fails
- User sees refund available
- Claims
- Balance restored

Mockup registry key: `concept/nft-gallery` (React UI on the live standard page).

## Related Standards

- ERC-5507: NFT refund windows complement fungible escrow

- ERC-20: Fungible tokens sold through escrow mechanism

## Technical Notes

ERC-5528 escrow sales use explicit state machine; never merge escrowed funds with wallet spendable balance.