EST. 2023 — Token Bound Function Oracle AMM

From one standard to products on two chains:
ERC-7527, the Function Oracle AMM, explained

NFTs that carry their own pricing function and liquidity — no buyers, no LPs, no order book. This site walks through the complete stack built by the author of ERC-7527: the reference implementation, a production auction-pricing engine, and two generations of frontends on Ethereum and BNB Chain.

01
EIP draft · ERC-7527
04
Repositories
02
Chains · Ethereum + BNB
01
Pricing paradigm · FOAMM
(01) TL;DR
FOAMM in three lines

What does this system do?

The core idea fits in three sentences:

N°1 — LIQUIDITY

Wrapping is liquidity

Users wrap ETH or ERC-20s into an NFT and can unwrap any time at a function-quoted price. The contract itself is an always-on counterparty: an asset becomes tradable the moment it is issued.

N°2 — ORACLE

The function is the oracle

Prices come from a deterministic math function embedded in the contract (getWrapOracle / getUnwrapOracle) — no order book, no external price feed. That is FOAMM: the Function Oracle AMM.

N°3 — SOLVENCY

Structure is solvency

Symmetric pricing (reference implementation) or a LIFO price stack (production) guarantees by construction that the pool can always pay everyone out, in any exit order. Solvency comes from the data structure, not from trust.

(02) Repositories
Standard → code → product

Four repositories, one vertical stack

Repository owner lanyinzly (Lanyin/Elaine Zhang) is the first author of the ERC-7527 draft — a complete loop from standard → reference implementation → production contracts → product frontends.

Contracts · FoundryReference

EIP7527 — the reference implementation

The minimal runnable implementation of ERC-7527: Agency (escrow + market making), App (the NFT), and Factory (clone deployment). The README doubles as a full tutorial.

  • Linear pricing f(x) = k·(1 + x/100), k = basePremium
  • ClonesWithImmutableArgs: strategy params live in bytecode, zero storage reads
  • Symmetric wrap/unwrap pricing keeps the pool fully redeemable
Contracts · FoundryProduction engine

wrap-auction — the auction pricing engine

The production Agency strategy WrapV3Aution: replaces the linear curve with a time-decay auction, plus holder dividends, ERC-6551 revenue accounts, and ERC-7615 callbacks.

  • Q96 fixed-point math + 5-node rational interpolation + exponential decay
  • LIFO price stack: redemption price = last traded price, principal always redeemable
  • 5% fee → 3/5 to pool owner & vaults (rebase), 2/5 to holder dividends
  • 42 integration tests, ~95% lcov coverage
Frontend · Next.js 13Ethereum mainnet / Sepolia

wrap-interface — the protocol console

The full-featured Wrap Protocol frontend: bid for a .agency domain NFT → deploy your own pool via the factory → wrap/unwrap → staking / Uniswap integration, with The Graph powering price-history charts.

  • wagmi CLI + GraphQL codegen — solid engineering setup
  • dotAgency auctions: commit + priceNonce scheme
  • Talks to on-chain WrapV2 contracts (the repo engine is the V3 evolution)
Frontend · Vite + React 19BNB mainnet

wrapx_app — the consumer product (latest)

WrapX, the simplified product: anyone can deploy a pool in one click and wrap BNB/ERC-20 into a named NFT (WToken), pitched as a loyalty / retention "user–protocol relationship" credential.

  • deployWrapX(name, basePremium, maxSupply, token) — one call to launch a pool
  • Pluggable TokenURI engine + IPFS image management (apply-to-all)
  • The Graph Studio subgraph + Pinata IPFS
(03) Architecture
Four diagrams

How it all fits together

Four diagrams: how the repositories relate, how the on-chain contracts are organized, the full lifecycle of one trade, and the standards it builds on.

FIG.01The big picture: standard → contracts → apps → data

flowchart TB subgraph STD["Standards"] ERC7527["ERC-7527 draft
Token Bound Function Oracle AMM
(Elaine Zhang et al., 2023-09)"] end subgraph CONTRACT["Contracts (Foundry)"] EIP["EIP7527
reference implementation
linear pricing f(x)=k(1+x/100)"] AUCTION["wrap-auction
WrapV3Aution production strategy
time-decay auction + LIFO price stack
+ ERC-6551 + ERC-7615"] end subgraph FRONTEND["Applications"] WI["wrap-interface
Next.js · Ethereum
protocol console"] WX["wrapx_app
React 19 · BNB
consumer product WrapX"] end subgraph DATA["Data"] SG["The Graph subgraphs ×2"] IPFS["IPFS / Pinata"] end ERC7527 -->|"spec → code"| EIP EIP -->|"inherits IERC7527Agency/App"| AUCTION AUCTION -->|"WrapV2 ABI integration"| WI AUCTION -.->|"architectural lineage"| WX WI --> SG WX --> SG WX --> IPFS style ERC7527 fill:#16261b,stroke:#2bee4b,color:#e9f2ea style EIP fill:#1a221c,stroke:#c8d2c8,color:#e9f2ea style AUCTION fill:#1a221c,stroke:#2bee4b,color:#e9f2ea style WI fill:#1a221c,stroke:#91a194,color:#e9f2ea style WX fill:#1a221c,stroke:#fafffa,color:#e9f2ea

FIG.02On-chain architecture (Ethereum)

Each "pool" = one Agency + App pair cloned by the Factory via ClonesWithImmutableArgs; pool-owner revenue is rebased into the ERC-6551 account of their .agency NFT.

flowchart TB OWNER(("Pool owner")) -->|"wins auction → mint"| DOT["DotAgency NFT
(.agency domain-style asset)"] DOT -->|createAccount| TBA["ERC-6551 token-bound account
(revenue account)"] OWNER -->|"deployERC7527"| F["WrapV2Factory"] F -->|"clone + immutable args"| AG["Agency instance
escrow · pricing · dividends · feeCount"] F -->|clone| APP["App instance (Agent NFT)
ERC721Enumerable · naming · tokenURI"] AG <-->|"onlyAgency mutual binding"| APP USER(("User")) -->|"wrap: deposit assets"| AG AG -->|"mint NFT"| APP USER -->|"unwrap: burn & redeem"| AG AG -->|"rebase: 5/6 of fees"| TBA AG -->|"1/6 of fees"| V["Vaults
foundation / swap / staking / DAO"] AG -.->|"push callback (ERC-7615)"| PW["PushWhitelist"] style DOT fill:#16261b,stroke:#2bee4b,color:#e9f2ea style TBA fill:#16261b,stroke:#2bee4b,color:#e9f2ea style AG fill:#1a221c,stroke:#fafffa,color:#e9f2ea style APP fill:#1a221c,stroke:#91a194,color:#e9f2ea

FIG.03Lifecycle of one wrap → unwrap

sequenceDiagram participant U as User participant AG as Agency (auction engine) participant APP as App (NFT) participant TBA as Owner's 6551 account U->>AG: wrap(to, data) + payment AG->>AG: getWrapOracle() → auction quote + 5% fee AG->>APP: mint(to) → tokenId AG->>AG: push price onto stack push(swap) AG->>AG: fees: 3/5 → feeCount, 2/5 → holder dividends AG-->>U: NFT (WToken) Note over U,AG: Time passes — others wrap, the price climbs the curve… U->>AG: unwrap(to, tokenId) AG->>APP: burn(tokenId) AG->>AG: read top of stack, then pop() AG-->>U: top price − 5% fee + accrued dividends Note over AG,TBA: Anyone can call rebase() AG->>TBA: feeCount × 5/6 → pool owner

FIG.04Standards dependency graph

flowchart LR AUC["wrap-auction implementation"] --> E7527["ERC-7527
FOAMM core"] AUC --> E6551["ERC-6551
token-bound accounts"] AUC --> E7615["ERC-7615
atomic push hooks"] E7527 --> E721["ERC-721 / Enumerable"] E7527 --> E20["ERC-20"] E7527 --> E1167["EIP-1167 + CWIA
minimal proxy clones"] E7527 -.-> E5679["ERC-5679
mint/burn extension"] style E7527 fill:#16261b,stroke:#2bee4b,color:#e9f2ea style AUC fill:#1a221c,stroke:#fafffa,color:#e9f2ea
(04) Mechanism
Two curves, one stack

Two pricing curves and one price stack

The reference implementation makes its case with the simplest possible linear curve. The production engine swaps in a time-decay auction: price jumps on every trade, decays over time, and never falls below the last traded price. The charts and simulator below make this concrete.

Linear bonding curve (EIP7527 reference)

f(x) = k·(1 + x/100), k = 0.1 ETH. The n-th NFT costs (n−1)% more than the first. Fully deterministic, hand-computable, arbitrage-free.

Time-decay auction premium (wrap-auction)

Time since the last trade → premium multiple over the last price. Schematic, approximated from the source (Q96 fixed-point + rational interpolation + expWad).

LIFO price-stack simulator — why can the pool always pay?

Each wrap pushes the traded price onto a stack (simplified here as +3% per trade); each unwrap redeems at the top of the stack (the most recent traded price) and pops it. Watch how the pool's principal always equals the exact sum of the prices on the stack — solvency is structural.

0
NFTs outstanding
0.000 ETH
Pool principal
0.100 ETH
Next wrap price
Unwrap payout (top of stack)
✓ Fully redeemable
Principal = sum of stack

Mind the LIFO semantics: you redeem at the latest traded price, not at your own entry price — early buyers who exit late capture the curve's upside. Exit order is a game.

Prices are not discovered — they are computed.
Solvency is guaranteed by structure, not by trust.
— FOAMM · the design philosophy of the Function Oracle AMM
(05) Highlights
Six theses

Six highlights

1

Paradigm-level: a function oracle for long-tail liquidity

AMMs need LPs, order books need counterparties, NFT markets need buyers. FOAMM embeds price as a deterministic function: liquid at issuance, zero cold start, no impermanent loss.

2

"Unwrappability" as a security invariant

Symmetric pricing / the LIFO price stack make "the pool can always pay" a mathematical property of the data structure — not a promise backed by governance or over-collateralization. A clean security philosophy.

3

Clones + immutable args, taken to the limit

Each pool's strategy parameters are appended to the proxy bytecode — zero storage reads, ultra-cheap pool creation, and parameters that are tamper-proof by construction.

4

Protocol revenue as an NFT (ERC-6551)

Pool revenue flows into the token-bound account of the .agency NFT; the income right transfers automatically with the NFT — "running a pool" becomes "holding a yield-bearing NFT".

5

Hooks built for composability (ERC-7615)

unwrap atomically pushes callbacks to whitelisted contracts, letting lending, liquidation, or auto-compounding protocols consume "unwrap" events in real time.

6

A complete loop: standard → implementation → product

The EIP author personally shipped the standard, the flagship protocol (Ethereum), and the consumer product (BNB) — rare in the EIP ecosystem.

(06) Risks & Issues
Mitigations & checklist

Risks and open issues

From a full source review, in two parts: first, what the production implementation (wrap-auction) already guards against; then a checklist for anyone planning to implement this open standard themselves.

What the shipped implementation already guards against

Each measure below is directly verifiable in the WrapV3Aution source.

Shipped

A standard reentrancy lock

WrapV3Aution inherits OpenZeppelin ReentrancyGuard; wrap / unwrap / rebase are all nonReentrant — replacing the fragile totalSupply-delta assertion used by the reference implementation.

Shipped

SafeERC20 on every token path

All fund flows use safeTransfer / safeTransferFrom, so non-standard tokens (USDT-style) no longer fail silently.

Shipped

Caller-side slippage protection

wrap takes a caller-supplied slippagePrice and reverts (WrapV3AutionExceededSlippagePrice) if the on-chain quote exceeds it — no overpaying when the quote jumps between signing and inclusion.

Shipped

Solvency by construction

The LIFO price stack (autionPriceList) plus the basePremium anchor make the redemption price always equal the last traded price — the pool stays fully redeemable by construction, with no reliance on governance.

Shipped

Test discipline

42 integration tests at ~95% lcov coverage across the wrap / unwrap / rebase / dividend paths.

Implementing ERC-7527 yourself? Seven things to check

ERC-7527 is an open standard — anyone can ship their own Agency / App. The reference implementation is a teaching template, not a security baseline. Before you build:

01

Use a standard reentrancy guard

Don't copy the reference implementation's totalSupply-delta assertion, and re-examine its transfer-before-mint ordering before reusing any of it.

02

Asset and id hygiene

Use SafeERC20 throughout; let tokenIds auto-increment or be assigned by App.mint instead of trusting external calldata.

03

Preserve the unwrappability invariant

Any custom pricing function must keep pool principal ≥ the total owed to all outstanding NFTs, for every possible exit order. Symmetric pricing and the price stack are both just means to this end.

04

Make pricing constants verifiable

Publish the derivation scripts for any fitted constants and add differential / invariant tests. The auction curve's Q96 magic numbers — unverifiable on-chain — remain this stack's biggest unclosed blind spot.

05

Map deployments to source and audits

Publish a "deployed address ↔ source commit ↔ audit report" mapping. The current divergence between the on-chain V2 contracts and the repo's V3 source is the cautionary tale here.

06

Mind the economic edge cases

At tiny supply the earliest minters capture outsized dividends (add a minimum-supply threshold or weighting), and the rounding dust from fee splits needs a defined home.

07

Tell users about LIFO

The redemption price is the latest traded price, not the holder's cost basis. A frontend that hides this is storing up complaints and broken trust — surface it next to every unwrap button.

(07) Ecosystem
Standards & siblings

How does it relate to everything else?

The standards it depends on, and its conceptual siblings.

ERC-7527 · FOAMM itself ERC-721 · NFT representation ERC-20 · denomination EIP-1167 + CWIA · clone deployment ERC-6551 · token-bound accounts ERC-7615 · atomic push ERC-5679 · mint/burn extension The Graph · indexing IPFS · metadata
Conceptual siblingWhat's similarWhat's different
Bonding curves / friend.tech / pump.funPrice moves along a fixed function with supply; the contract is the counterpartyWrapX tokenizes a "user–protocol relationship", and holders share fees from later participants
Gradual Dutch Auctions (Paradigm)Price jumps on each sale + exponential time decaywrap-auction adds a hard floor at the last traded price, plus rational-interpolation smoothing
NFT AMMs (sudoswap / NFTX)Both provide on-chain liquidity for NFTssudoswap still needs LPs to seed liquidity; FOAMM removes even that step
DeFi 2.0 (OlympusDAO)rebase, vaults, protocol-owned liquidity, dividendsWrapX's principal redemption is structurally guaranteed by the price stack, not a (3,3) game
ENS / domain assetsdotAgency is ENS-style naming + resolverA .agency name itself earns yield (pool revenue accrues to its 6551 account)
(08) Future
Near / mid / far

Where can this be applied?

Three tiers, ordered by distance from the existing code.

Near · the architecture supports it today

Liquidity & membership economies

Mid · needs new contracts / economic design

Structured finance & game economies

Far · needs research / standard maturity

Composable financial primitives

(09) FAQ
Quick answers

Frequently asked questions

Short, self-contained answers to the questions people — and AI assistants — ask most about ERC-7527.

What is ERC-7527?
ERC-7527 is an Ethereum standard — the Token Bound Function Oracle AMM — that lets an NFT carry its own on-chain pricing function and liquidity. It can be minted (wrapped) and redeemed (unwrapped) directly against the contract, with no buyer, liquidity provider, or order book. It was authored by Elaine Zhang and collaborators and published as a draft in September 2023.
What is FOAMM (the Function Oracle AMM)?
FOAMM stands for Function Oracle AMM. Instead of pricing from an order book or an external price feed, the price is produced by a deterministic math function embedded in the contract (getWrapOracle / getUnwrapOracle). The function itself acts as the oracle.
How is ERC-7527 different from bonding curves like friend.tech or pump.fun?
All of them move price along a fixed function with the contract as the counterparty. ERC-7527 differs in three ways: the wrapped asset represents a user–protocol relationship credential, the pool's solvency is guaranteed structurally (by a LIFO price stack or symmetric pricing), and holders can share the fees paid by later participants.
Why is an ERC-7527 pool always solvent?
Redemption pays the most recent traded price held on a LIFO price stack (in the production wrap-auction engine) or uses symmetric pricing (in the reference implementation). The pool's principal always equals the exact sum of the prices it owes, so it can pay every holder out in any exit order — solvency is a property of the data structure, not of trust or governance.
What does LIFO redemption mean for holders?
When you unwrap, you are paid the latest traded price (the top of the stack), not your own entry price. Early buyers who exit later capture the curve's upside, so exit order is part of the game. Frontends should make this explicit next to every unwrap action.
What is WrapX?
WrapX is the consumer product built on ERC-7527, deployed on BNB Chain. Anyone can launch a pool in one click and wrap BNB or ERC-20 tokens into a named NFT (a "WToken"), positioned as a loyalty or membership credential.
Who created ERC-7527?
The standard's first author is Elaine (Lanyin) Zhang, who also built the reference implementation (EIP7527), the production auction engine (wrap-auction), and two frontends — wrap-interface on Ethereum and WrapX on BNB Chain.