ERC-7527: Token Bound Function Oracle AMM Contract

This proposal defines a system which embeds a Function Oracle that can wrap fungible tokens to non-fungible token and unwrap the non-fungible back to fungible tokens. The preset Function Oracle provides its own Automated Market Maker(AMM) so that it standardize the process of a creating pool for the issuer of vouchers.

Under current framework of pool, it is hard for user to define how to manage the pool without coding. However, we believe it should be more accessible for users to define and create their own pools to energize the market. Through employing FTs as premium for NFTs under a customizable framework, such an approach standardize the process of creating a pool and allows users to gain the ability to “do it yourself.”

We want to propose an infrastructure for decentralized platforms and prompt the development of the decentralized voucher system.

1 Like

Very good idea, can you expand on it?

Where can I view the code? I want to develop the core components of a full-chain game based on this.

You can click the GitHub link and find the most updated version under “commits.”

The current version is: Add EIP: Token Bound Function Oracle AMM Contract by lanyinzly · Pull Request #7797 · ethereum/EIPs · GitHub

Keep clicking the blue “Expand Down” Button at left bottom corner if you cannot see the full script.

Yes, we will continue post our updates for rationale and more general ideas behind the design. And we will provide some examples on how to implement it and possibilities for future application.

Looking forward to approval!

Very good idea,Looking forward to approval!

This is awesome. By standardizing the process of creating a pool for voucher issuers, this system provides liquidity to credit assets. This liquidity can make credit assets more accessible and tradable in various scenarios.

The EIP7797 is very cool. This will be a disruptive asset issuance protocol. I think there are at least two things that are subversive:

Asset issuance rights are controlled by users, not the so-called project parties
Asset issuance has sufficient liquidity.
The project party only formulates the rules for asset issuance. Both project parties and users need to mint assets according to the rules, and these assets will automatically enter the Pool. Any asset holder can redeem their assets at any time. Not only NFT artists, but also games, social media, and even any influential organization or individual can use this standard to issue assets without worrying about unfair asset issuance and insufficient asset liquidity. Very good, looking forward to further development.

1 Like

Perhaps, EIP-7797 will become the infrastructure for decentralized credit in the crypto world

1 Like


These two requirements seem weird together:

Accounts MUST implement a receive function.
Accounts MAY perform arbitrary logic to restrict conditions under which Ether can be received.

So it’s perfectly valid for an implementation to reject all ether, but it still has to define a receive function?

If Factory is implemented, it does not distinguish what kind of currency would be received by the Agency. For conciseness, we require Agency to implement a receive function.

We can change it to be when Factory is implemented and able to accept ETH as Asset, accounts in Agency MUST implement a receive function.

So it’s perfectly valid for an implementation to reject all ether, but it still has to define a receive function?

This case can happen if Agency only accepts ERC20.