Overview

How to price and invest in early ideas or applications is a huge challenge in the decentralized world. ERC7527 follows the consensus of "credit creates currency" and proposes a paradigm of decentralized pricing based on Premium-driven.

In this article, we will delve into the principles and protocol details of ERC7527, further introduce the operation principle and its huge advantages of the continuous quoting model. At the same time, we will also introduce some extended applications based on the programmability and composability of ERC7527.

ERC7527

In the previous article, we introduced the commonly used on-chain pricing models, including the special continuous quoting model of ERC7527 and provided the mathematical representation of the model. However, the introduction of ERC7527 in the previous article was relatively simple. In this section, we will focus on the principles and protocol details of ERC7527.

ERC7527 proposes a new paradigm of pricing applications by issuing ERC7527 tokens. The price of ERC7527 tokens actually quantifies the market value of the application (Application Market Value = ERC7527 Price × Quantity). This method transforms the pricing of applications into the pricing of ERC7527 tokens. The pricing of ERC7527 tokens is divided into the following two parts:

• Quoting. ERC7527 provides interfaces for external buying (wrap) and selling (unwrap) quotes, allowing developers to implement them on their own.
• Pricing. Based on ERC7527, the FOAMM (Function Oracle Automated Market Maker) realizes buying pricing by adding internal liquidity through wrap, or selling pricing by removing internal liquidity through unwrap. This solution does not rely on external liquidity providers.

For the issue of buying quotes and pricing of ERC7527 tokens, ERC7527 provides full programmability. Specifically, users can call the following function to obtain quotes:

Developers of ERC7527 need to design a quoting model during the development process to ultimately provide quotes. After users call getWrapOracle to obtain the current quote, they can choose to inject liquidity into the ERC7527 pool to achieve the conversion from quote to pricing. Specifically, users can call the wrap function within FOAMM to inject liquidity:

For the issue of selling quotes and pricing of ERC7527 tokens, ERC7527 uses the pool constructed by FOAMM to solve the conversion from selling quotes to pricing. Users can use the pool to destroy assets and remove internal liquidity to exit. There may be a question here, which is the provider of liquidity in the pool.

As mentioned earlier, FOAMM adds internal liquidity through wrap, which is the source of liquidity in the pool. ERC7527 uses FOAMM to inject the liquidity paid by users for buying assets into the pool to act as exit liquidity. For developers, they only need to provide selling quotes, and because there is liquidity in the pool, the selling quote is the selling price. Specifically, developers need to implement the following function to provide selling quotes:

Developers can construct any selling quote function based on the liquidity of the pool. It should be noted that the selling quote should ultimately maintain the balance of the pool. Users can call getUnwrapOracle at any time to obtain the current selling quote of ERC7527 tokens and can choose to further call the unwrap function within FOAMM to destroy the ERC7527 tokens held and obtain the quantity of tokens for the selling quote in the pool:

In summary, for users, the interaction with ERC7527 involves only two parts:

• Call the getWrapOracle function to read the current buying quote. If the buying quote is suitable, call the wrap function to inject liquidity and obtain ERC7527 tokens.
• Call the getUnwrapOracle function to read the current selling price. If the selling price is suitable, call the unwrap function to destroy the held ERC7527 tokens and obtain the quantity of tokens for the selling quote in the pool.

The return values of the getWrapOracle and getUnwrapOracle functions provided in the previous text both include the options of price and fee. Where price represents the quantity of tokens required to wrap or unwrap ERC7527 tokens, and fee represents the handling fee. Regardless of the wrap or unwrap operation, users need to pay a certain amount of handling fee, which is eventually designated for users to withdraw.

ERC7527 is a standard token, similar to ERC20 tokens, and also has its token address. ERC7527 has the following defined fields:

The above struct defines the most core attributes of ERC7527, where currency represents the token provided by the user to mint ERC7527 tokens, premium indicates the initial quote of ERC7527 tokens, feeRecipient represents the address for handling fees during the wrap and unwrap interaction, and mintFeePercent and burnFeePercent represent the handling fee rates for wrap and unwrap.

ERC7527 tokens have the fluctuating feature of premium. The term "price" is used in the function definitions in the previous text, specifically within the Asset struct, representing premium.

ERC7527 defines three different modules:

1. App The App contract address is the ERC7527 token contract address. ERC7527 requires the App contract to inherit relevant interfaces of ERC721Metadata. Additionally, this contract needs to expose the mint and burn interfaces for the convenience of pool calls, and the mint and burn interfaces can only be called by the pool to avoid malicious minting of ERC7527 tokens leading to unbalanced pool liquidation.
2. Agency The Agency is the contract where the pool and FOAMM are located, and it is also the core contract for user interaction. The functions mentioned earlier, such as getWrapOracle/wrap/getUnwrapOracle/unwrap, are all located in this contract. This contract stores the tokens injected by users during buying (wrap) for use when users exit (unwrap). This contract is responsible for the liquidation of ERC7527 tokens.
3. Factory This is an auxiliary contract, and its function is to simplify the deployment of App and Agency for the convenience of users to deploy ERC7527 tokens.

The relationship between the three components can be referred to in the following diagram:

The App and Agency within ERC7527 are mutually bound. From a code perspective, the mint and burn functions of App can only be called by Agency, and ERC7527 also specifies a series of functions to allow users to query the Agency address (getAgency function) when the App is known, and to query the App address (getStrategy function) when the Agency is known.

From a liquidity perspective, each ERC7527 token within App has corresponding liquidity in the pool, ensuring the balance of the pool's liquidation.

This decentralized pricing solution using ERC7527 tokens for applications is a revolutionary innovation, introducing a new paradigm of issuing currency before establishing applications. For early-stage applications, developers can directly use ERC7527's Factory to deploy ERC7527 tokens.

Users can call the wrap function to mint ERC7527 tokens to participate in early-stage investments in projects, and can also call the unwrap function to exit their investments. For developers, the price of ERC7527 tokens can provide effective market value for early-stage applications. As the application develops and the number of ERC7527 token holders increases, the application's market value grows, providing incentives for both ERC7527 token holders and application developers to benefit from the increase in market value.

Continuous Quoting Model

In the previous section, we thoroughly discussed the operation principles of ERC7527, but did not provide a detailed introduction to the construction of the buying quoting model. In this section, we will propose a more general buying quoting model.

The buying quoting of ERC7527 should consider both micro and macro perspectives.

From a macro perspective, we expect the quoting of ERC7527 tokens to increase with the increase in the quantity of ERC7527 tokens held. Specifically, the current quoting of ERC7527 tokens obtained by calling getWrapOracle should not be lower than the pricing (or "last buying transaction price").

The increase in the quoting of ERC7527 tokens with the increase in the quantity of ERC7527 tokens held will lead to an interesting result, namely, the ERC7527 tokens themselves will have a credit expansion mechanism. Specifically, the market value of ERC7527 tokens may exceed the Total Premium Locked (TPL). This credit expansion mechanism will enable each holder of ERC7527 tokens to gain credit growth.

In the previous text, we did not mention the selling transaction of unwrap, which directly leads to a decrease in the quoting of the buying transaction. We can use a simple stack-based system to implement a selling-driven decrease in the quoting of the buying transaction:

We store all historical pricings of ERC7527 tokens in the stack. When a new pricing "new price" is formed, we push it into the stack. The buying quoting model will depend on the latest pricing in the stack to provide the buying quote.

When a user sells, we directly use the latest buying pricing "new price" as the selling price, transfer liquidity from the Agency to the user, and simultaneously pop this pricing from the stack. At this point, the quoting model still depends on the latest pricing "price2" in the stack to provide the quote to the outside.

Since "price2" is less than "new price", the quoting model will provide a quote based on "price2" to the outside after the unwrap, which will be lower than the quote based on "new price" in the past. Of course, this stack-based selling quote is just a simple selling quote solution.

From a micro perspective, the quoting model should have a price adjustment mechanism similar to a Dutch auction. The most significant feature of a Dutch auction is the introduction of time into the quoting model, where the price should automatically decrease with a long period of no transactions.

However, the Dutch auction has a serious drawback. As the price will inevitably decrease over time, there is a prisoner's dilemma of waiting games, ultimately leading to continuously decreasing quotes. A good quoting model at the micro level should include a time factor and should have both an upward and downward phase.

In summary, a good quoting model should meet the following requirements:

• The provided buying quote should not be lower than the formed pricing. This is to ensure that with the increase in the quantity of ERC7527 tokens held, both the buying quote and pricing increase.
• The specific quoting function should have a time factor and should include both an upward and downward phase.

In addition, we hope that the quoting model can meet the growth patterns of applications:

• Early stages should have high growth potential.
• Later stages should have relatively stable growth potential.

We will provide a specific solution in the following text.

First, meeting the macro requirements is actually quite simple. We need to include the pricing (Pn-1) as a factor in the quoting model. Then, for the micro requirements, we can segment the function to solve the problem. Ultimately, we can obtain the following quoting function:

For the specific meanings of the parameters in this quoting function, readers can refer to the introduction given in the previous article. Here, we directly provide the graph of this pricing function:

In the above graph, the x-axis represents the time interval from the last transaction, and the y-axis represents the ratio of the current quote to the last transaction price. It is worth noting that when the price drops below the last transaction price, the quoting model will only provide a quote equal to the last transaction price, to meet the macro requirements of the quoting model.

We can intuitively see that the above quoting model has both an early upward phase and a later downward phase similar to a Dutch auction, effectively meeting the micro requirements of the quoting model. Here, we can see that in the early upward phase, there is a jump in order to avoid a situation where the quantity of ERC7527 tokens increases during continuous minting but the price does not change significantly.

We have created an environment to simulate the above quoting model, and the simulation results are as follows:

In the simulated trend candlestick chart, the first column represents the price trend of the current ERC7527 tokens, and the second column represents the current quantity of ERC7527 tokens, which increases with wrap operations and decreases with unwrap operations. From a code perspective, the second column is actually obtained by calling the totalSupply function of App. The third column represents the current number of wrap and unwrap operations, where the green line represents the number of wrap operations, and the red line represents the number of unwrap operations.

The chart shows the early operation of some pools in the simulation. In the early stages, due to reasons such as insufficient consensus, users enter and exit, causing the pricing to fluctuate around the initial price for a long time, until some positive developments occur, users choose to buy in but are then sold off by early users, returning to the initial price. Finally, as the number of ERC7527 token holders increases, the pricing oscillates upward in the fluctuation.

Through the simple simulation above, we can see a crucial advantage of the continuous quoting model, which is that the user's buying operation directly affects the quoting process, leading to almost no possibility of two ERC7527 tokens having the same candlestick chart, greatly increasing the complexity of the system's game.

The following image shows a specific change in quoting, where B represents buying (wrap) and S represents selling (unwrap). We can see that the entire quoting model, at a macro level, ensures that the price of each buying transaction is not lower than the price of the previous transaction, and each selling transaction uses the previously existing buying price, resulting in a certain degree of symmetry in the image.

In fact, we have addressed the macro and micro requirements of the quoting model mentioned above, and have also met the growth pattern of "early stages having high growth potential" in quoting. Next, we need to address a problem: how to achieve stable growth in quoting in the later stages of an application. The high growth in early quoting is matched with the early high growth of the application. The quoting in the middle and later stages needs to match the stable development of the application, so we need to build a stable growth quoting system in the middle and later stages.

Therefore, we have decided to solve this problem through segmentation, using a high-growth quoting system in the early stages and a stable growth quoting system in the later stages. Of course, in addition to the early and later stage segmentation introduced in this article, developers can further segment the quoting function based on their own situations, such as using different growth functions in the early, middle, and later stages.

In fact, we still use the same quoting function as in the early stage, but have modified some of its parameters. The modified quoting function curve is as follows:

Compared to the early stage quoting function, we can see that the initial increase in the later stage quoting function is lower. The x-axis in the above graph still uses the time interval since the last transaction as the unit, but it is important to note that this time unit is smaller than that of the early stage quoting function.

We attempted to simulate the price changes during the supply of ERC7527 tokens from 0 to 20,000, and obtained the following trend candlestick chart:

The initial price set in the above trend candlestick chart is 0.1. When the supply reaches 20,000, the price increases from the initial 0.1 to 300, a 3000-fold increase.

Of course, some applications may not have a smooth path to success. The following trend candlestick chart shows the price changes in the early stage of vigorous development, followed by a sudden crisis leading to user exits:

The above cases demonstrate that the quoting model we proposed is effective, meeting the growth patterns of applications with high growth in the early stages and stable growth in the later stages. These advantages are due to the segmented quoting model, using different quoting functions with different parameters in the early and later stages.

On the other hand, because the quoting function is continuous, users can wait for the quoting function to provide the expected quote, and the specific quoting situation will change with user behavior. This means that in the quoting model introduced in this section, there is not only a game between users and the quoting model, but also a game between users. The game between users is extremely complex, making it difficult to deduce a strategy to obtain risk-free returns based on the quoting model.

Expanded Applications

In this section, we will introduce several expanded applications of ERC7527:

• ERC7527 as an incentive layer for AI applications
• ERC7527 as an atomic oracle for other applications, especially lending applications

Incentive Layer for AI Applications

AI applications need a new incentive layer, and ERC7527 can provide a systematic incentive layer for AI applications, with ERC7527 tokens being the core asset of the incentive layer.

By deploying ERC7527 tokens for pricing in the earliest stages of development, AI applications gain a market-recognized valuation, and users can directly invest in AI applications by using the wrap operation to hold ERC7527 tokens.

From a market value perspective, with the development of AI applications and the increase in the quantity of ERC7527 tokens held, both the developers of AI applications and the holders of ERC7527 tokens will receive significant incentives from the increase in market value.

AI applications can also further incentivize users through dividend measures. AI applications directly require users to use tokens for payment on the Ethereum Layer 2.

Users can call the contract to pay for the AI application. The fees locked in the payment contract are regularly transferred to the dividend contract. ERC7527 token holders can directly withdraw profits from the dividend contract, and AI application developers can also withdraw another portion of the profits from the dividend contract.

In terms of technical implementation, ERC7527 tokens inherit ERC721, which means that ERC7527 tokens can generate ERC6551 account contracts using the ERC6551 protocol. We can use some technical solutions to cross-chain the ERC6551 accounts of ERC7527 tokens to the Ethereum Layer 2. The specific technical implementation path is as follows:

After users hold ERC7527 tokens, they can call the ERC6551 factory contract on the Ethereum mainnet to deploy an ERC6551 account for the ERC7527 tokens, and then use the ERC6551 account to call the bridge contract deployed on the mainnet. The bridge contract will use the cross-chain bridge to call the ERC6551 factory contract on the Ethereum Layer 2 to deploy an ERC6551 account for the user on the Layer 2.

There is a simple implementation of the ERC6551 cross-chain, and developers can refer to the code in the ERC6551Mirror repository, which uses Chainlink CCIP to implement the cross-chain operation of ERC6551.

After the ERC6551 cross-chain is completed, users can use the ERC6551 account to withdraw rewards from the dividend contract.

Atomic Oracle

ERC7615 is an interesting ERC that specifies an atomic push relationship between generic contracts. This simple push protocol can construct an atomic oracle, significantly reducing the development difficulty of protocols such as lending protocols.

The operation principle of ERC7615 is as shown in the following diagram:

When a user (Client) calls certain functions of a sending contract (Publisher), the sending contract will check if there are any subscription contracts, and if so, it will call the exec function of the subscription contract to push some content. The most significant feature of the above process is atomicity. If the subscription contract encounters a problem in processing the pushed data, the transaction calling the push contract (i.e., the "Call somefunc(…)" transaction in the diagram) will directly fail.

In ERC7527, we have mentioned multiple times that the selling quote provided by ERC7527 is actually the selling price, and any user holding ERC7527 tokens can withdraw liquidity from the Agency using the selling price. So, can we push the selling price of ERC7527 to lending protocols to achieve liquidation within lending protocols?

The answer is yes. And because the continuous quoting model at a macro level follows the property that the selling price increases with the increase in the quantity of ERC7527 held, the lending protocol does not need to be concerned with the wrap operations within ERC7527, but only needs to be concerned with the unwrap transactions that would cause the price to decrease.

We can embed the push mechanism of ERC7615 within the unwrap function, directly pushing the current selling price of the unwrap to the lending protocol. When the lending protocol receives the pushed unwrap price, it can use the price information to liquidate positions within the lending protocol that use ERC7527 tokens as collateral.

Once a lending position needs to be liquidated, the lending protocol can execute the unwrap operation to withdraw liquidity from the ERC7527 Agency to close the lending position.

What's particularly exciting is that the above operations are atomic, meaning that if the liquidation of the lending protocol fails, the unwrap operation of ERC7527 will also fail, which means that the lending protocol completely avoids the risk of under-collateralization.

In fact, any protocol can obtain the pushed selling price of ERC7527 within ERC7527, which means that developers only need to write an ERC7615 receiving interface to obtain the pricing of an asset and further complete other operations.

Within ERC7527, because ERC7527 tokens inherit ERC721 on the contract, developers can empower ERC7527 tokens with other capabilities. When users use traditional staking solutions, such as directly transferring ERC7527 to a staking contract, users lose the other rights of ERC7527 tokens. Therefore, ERC7527 tokens need a new staking solution that does not require asset transfer.

Based on the push mechanism of ERC7615, a staking solution that does not require asset transfer can be designed. Specifically, establish a push relationship between the unwrap in the ERC7527 Agency contract and the staking contract. Staking users can interact with the ERC7527 staking contract to stake ERC7527 tokens, but this process does not require transferring ERC7527 tokens into the staking contract.

At this point, ERC7527 tokens can receive dividends within the staking contract. When a user unwraps the staked ERC7527 tokens, the Agency contract will use ERC7615 to push this message to the staking contract, and the staking contract will release the staked status of the specified ERC7527 tokens and perform the final liquidation.

In this process, ERC7615 ensures the liquidation of the staking system, ensuring that destroyed ERC7527 tokens cannot receive staking rewards.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。