Overview

How to price early-stage ideas or applications and participate in investment is a significant challenge in the decentralized world. ERC7527 proposes a paradigm of decentralized pricing based on Premium-driven consensus, following the “credit creation of money” concept.

In this article, we will delve into the principles and protocol details of ERC7527, further explaining the operation principles of the continuous pricing model and its significant advantages. Additionally, we will explore expanded applications derived from ERC7527’s programmability and composability.

ERC7527

In the previous article, we introduced common on-chain pricing models and briefly touched upon ERC7527’s unique continuous pricing model, including its mathematical representation. However, the previous article provided only a simple overview of ERC7527. In this section, we will focus on the principles and protocol details of ERC7527.

ERC7527 introduces a new paradigm for pricing applications by issuing ERC7527 tokens. The price of ERC7527 tokens effectively quantifies the market value of the application (Application Market Value = ERC7527 Price × Quantity). This approach transforms application pricing into pricing ERC7527 tokens.

The pricing of ERC7527 tokens consists of two main parts:

Quotation: ERC7527 provides interfaces for external buying (wrap) and selling (unwrap) quotations, allowing developers to implement these functionalities themselves.

Pricing: ERC7527’s FOAMM (Function Oracle Automated Market Maker) provides buying pricing by adding internal liquidity via wrap or selling pricing by removing internal liquidity via unwrap. This approach does not rely on external liquidity providers.

Regarding the issue of buying quotations and pricing for ERC7527 tokens, ERC7527 offers extensive programmability. Specifically, users can invoke functions to obtain quotations:

In ERC7527, developers need to design a quotation model during the development process to ultimately provide quotations. When users call getWrapOracle to obtain the current quotation, they can choose to inject liquidity into the ERC7527 pool to convert quotations into pricing. Specifically, users can use the wrap function within FOAMM to inject liquidity:

For the selling quotation and pricing of ERC7527 tokens, ERC7527 utilizes pools built with FOAMM to facilitate the conversion from selling quotation to pricing. Users can use these pools to destroy assets or remove internal liquidity to exit. However, a key issue arises regarding who provides liquidity to these pools.

As mentioned earlier, FOAMM adds internal liquidity through wrap operations, which serves as the primary source of liquidity within the pools. ERC7527 uses FOAMM to inject the liquidity paid by users when they buy assets into the pools, which acts as the exit liquidity.

Developers, only need to provide the selling quotation because there is already liquidity within the pools. Therefore, the selling quotation effectively serves as the selling price. Specifically, developers need to implement the following function to facilitate the selling quotation:

Developers can construct arbitrary selling quotation functions based on the liquidity in the pools. It’s important to ensure that the selling quotation maintains the liquidity balance within the pools. Users can call getUnwrapOracle at any time to retrieve the current selling quotation for ERC7527 tokens. They can further choose to call FOAMM’s unwrap function to destroy ERC7527 tokens and receive tokens equivalent to the amount quoted in the pool.

For users interacting with ERC7527, there are two main actions:

Call getWrapOracle function to retrieve the current buying quotation. If suitable, call wrap to inject liquidity and receive ERC7527 tokens.

Call getUnwrapOracle function to retrieve the current selling price. If suitable, call unwrap to destroy held ERC7527 tokens and withdraw tokens equivalent to the selling price from the pool.

Both functions return values with price and fee options. price represents the amount of tokens required for wrap or unwrap operations, while fee denotes the transaction fee. Users must pay fees for these operations, with fees claimable by specified users.

ERC7527, like ERC20 tokens, has its own token address and defines specific fields.

The above struct defines the core attributes of ERC7527. currency represents the token users provide to mint ERC7527 tokens, premium denotes the initial price of ERC7527 tokens, feeRecipient specifies the address that receives fees during wrap and unwrap interactions, while mintFeePercent and burnFeePercent indicate the fee rates for wrap and unwrap operations.

ERC7527 tokens feature a premium with fluctuating characteristics. The term price is used in the function definitions above, specifically within the Asset struct to represent premium.

ERC7527 is structured into three distinct modules:

App: The contract address where ERC7527 tokens are deployed. An App contract in ERC7527 must inherit interfaces like ERC721Metadata. It exposes mint and burn interfaces for pool calls only, preventing malicious minting and ensuring pool liquidity balance.

Agency: This contract acts as the core interface for pools and FOAMM interactions mentioned earlier. Functions such as getWrapOracle, wrap, getUnwrapOracle, and unwrap are implemented here. The Agency contract stores tokens injected by users during wrap operations for subsequent use during unwrap operations, facilitating ERC7527 token liquidation.

Factory: An auxiliary contract designed to simplify the deployment of App and Agency contracts, making it easier for users to deploy ERC7527 tokens.

The relationships between these components are illustrated in the diagram below:

In ERC7527, the App and Agency contracts maintain a bidirectional binding relationship. From a code perspective, the mint and burn functions of App can only be called by Agency. ERC7527 also defines a series of functions to facilitate querying the Agency address given an App (getAgency function), and querying the App address given an Agency (getStrategy function).

From a liquidity perspective, each ERC7527 token within App corresponds to liquidity in a pool. This ensures the liquidity balance of the pool.

This decentralized pricing solution using ERC7527 tokens represents a revolutionary innovation. It introduces a new paradigm where applications can be built upon the issuance of tokens. For early-stage applications, developers can directly deploy ERC7527 tokens using ERC7527’s Factory.

Users can participate in early-stage investments by calling the wrap function to mint ERC7527 tokens, or exit their investments by calling the unwrap function. For developers, the price of ERC7527 tokens provides an effective valuation for early-stage applications. As applications grow and more ERC7527 token holders participate, the application’s valuation increases, providing incentives for both ERC7527 token holders and application developers.

Continuous Quotation Model

In the previous section, we extensively discussed the operational principles of ERC7527, but did not detail the construction of the buy quotation model. ERC7527 provides the getWrapOracle interface here, with the specific implementation of the quotation model entirely reliant on the developer. In this section, we propose a more general buy quotation model for ERC7527.

The buy quotation for ERC7527 should consider both micro and macro perspectives:

From a macro perspective, we expect the price of ERC7527 tokens to increase with an increase in the number of ERC7527 tokens held. Specifically, the current price obtained from getWrapOracle should not be lower than the pricing (or “last buy transaction price”).

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

In the previous discussion, we did not mention the unwrap sell transaction, which directly causes the buy transaction price to decrease. We can use a simple stack-based system to implement a scheme where selling drives down the buy quotation, as follows:

In ERC7527, all historical pricing is stored in a stack. Each new price (new price) is pushed onto the stack when formed. The buy quote model relies on the latest price in the stack to determine the buy quote.

When a user sells, the latest buy price (new price) is directly used as the sell price. Liquidity is transferred from the Agency to the user, and the price is popped from the stack. At this point, the quote model still relies on the latest price (price2) in the stack to provide the quote after unwrap. Since price2 is less than new price, the quote model will provide a lower quote externally compared to what was based on new price in the past. However, this stack-based sell quote is a basic approach.

On a microscopic level, the quote model should include a price adjustment mechanism similar to a Dutch auction. A Dutch auction introduces time into the quote model, automatically lowering the price with extended periods of no transactions. However, Dutch auctions face a serious issue where prices inevitably decline over time due to a waiting game dilemma, leading to continuous price decreases. A robust quote model on a microscopic level should incorporate a time factor and include both upward and downward phases.

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

The buy quote should not be lower than the established pricing to ensure macro-level increases in buy quote and pricing with increasing ERC7527 token ownership.

The specific quote function should include a time factor and should have both upward and downward phases.

Additionally, we aim for the quote model to satisfy the growth patterns of applications:

High growth potential in the early stages

Relatively stable growth in the later stages

We will detail the solution in subsequent sections.

Initially, meeting macro-level requirements is straightforward by incorporating pricing (Pn-1) as a factor within the quote model. For microscopic demands, we can segment the function to resolve issues. Ultimately, we can achieve the following quote function:

The specific meanings of the parameters in this pricing function can be found in the introduction provided in the previous article. Here, we directly present the graph of this pricing function:

In the above graph, the x-axis represents the time intervals since the last transaction, and the y-axis represents the ratio of the current quote to the last transaction price. It’s noteworthy that when the price drops below the last transaction price, the pricing model only quotes the last transaction price to meet the macro requirements of the pricing model.

Visually, we observe both an early uptrend phase and a later descending phase similar to a Dutch auction in the above pricing model, effectively meeting the micro requirements of the pricing model. In the early stages of the uptrend phase, we see a jump in prices to prevent situations where the holdings increase under ERC7527’s continuous casting process without significant price changes.

We establish an environment to simulate the above pricing model, and the simulation results are as follows:

In the simulated candlestick chart, the first column represents the price trend of the ERC7527 token, while the second column indicates the current holdings of ERC7527 tokens, which increase with wrap operations and decrease with unwrap operations. From a code perspective, the second column actually retrieves the total supply using the App’s totalSupply function. The third column shows the number of wrap and unwrap operations, where the green line represents wrap operations and the red line represents unwrap operations.

The chart illustrates the early operational dynamics of some pools. Initially, due to insufficient consensus or other factors, users enter and exit, causing pricing to fluctuate around the initial price for a prolonged period. Eventually, positive developments attract buyers, but early users selling off returns the price to its initial level. As the number of ERC7527 token holders increases, the price oscillates upward within fluctuations.

Through this simple simulation, we observe a significant advantage of the continuous pricing model: user buy operations directly influence the pricing process, making it highly unlikely for two ERC7527 tokens to exhibit identical candlestick patterns. This greatly enhances the complexity of the system’s strategic interactions.

The following chart illustrates specific price changes, where ‘B’ denotes buy (wrap) and ‘S’ denotes sell (unwrap). We can see that macroscopically, each buy transaction’s execution price does not fall below the previous transaction price, while each sell transaction uses a previously established buy price, resulting in a certain symmetry in the chart.

We have effectively addressed both the macro and micro requirements of the pricing model described earlier, while also fulfilling the growth pattern of “early-stage high growth” in pricing. Next, we need to address a new challenge: how to achieve robust growth in pricing during the later stages of application development. The early rapid price increases align with the early high growth of the application. In the mid-to-late stages, pricing needs to match the application’s stable development, so we need to build a pricing system that supports robust growth in these later stages.

To tackle this, we’ve decided to address the issue through segmentation. Specifically, we’ll employ a high-growth pricing system in the early stages and transition to a stable-growth pricing system later on. Beyond the two-stage segmentation discussed here, developers can implement more segments based on their specific needs, such as using different growth functions for early, mid, and late stages.

In practice, we’re still using a pricing function consistent with the early stage but have adjusted some parameters. The modified pricing function curve is shown below:

Compared to the early-stage pricing function, we observe that the initial rate of increase in the later-stage pricing function is lower. The x-axis in the chart still uses time intervals since the last transaction as units, but it’s important to note that these intervals are shorter than those used in the early-stage pricing function.

We attempted to simulate the price changes of ERC7527 tokens during the period of supply increasing from 0 to 20,000, resulting in the following candlestick chart.

The initial price set for the above candlestick chart was 0.1. As the supply reached 20,000, the price increased from the initial 0.1 to 300, marking a 3000-fold increase.

Of course, not all applications follow a smooth path to success. The following candlestick chart illustrates price fluctuations during early vigorous growth followed by a sudden crisis leading to user withdrawals:

The above cases demonstrate the effectiveness of our proposed pricing model, which aligns with the growth patterns of applications by accommodating both early high growth and later stable growth phases. These advantages stem from the use of a segmented pricing model, employing different parameterized pricing functions for early and later stages.

Moreover, because the pricing function is continuous, users can anticipate expected quotes and these specifics can change based on user actions. This dynamic interaction not only involves a game between users and the pricing model but also between users themselves. Inter-user interactions are highly complex, making it difficult to reverse-engineer a strategy within this pricing model to achieve risk-free returns.

Expanded applications

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

1. ERC7527 as an incentive layer for AI applications.
2. ERC7527 as an atomic oracle for other applications, especially in lending.

AI application incentive layer

AI applications require a new incentive layer, and ERC7527 can provide a systematic incentive layer for these applications, with the ERC7527 token serving as the core asset of this layer.

In the early stages of AI application development, deploying ERC7527 tokens prices the application, establishing a market-recognized valuation. Users can directly invest in AI applications by acquiring ERC7527 tokens through wrap operations.

From a market value perspective, as AI applications grow and the amount of ERC7527 tokens held increases, both developers of AI applications and holders of ERC7527 tokens benefit greatly from the increase in market value.

AI applications can further incentivize users through dividend measures. They can require users to use tokens to pay for services directly on Ethereum’s Layer seek J even if Has even S even among Was even even Tech official Can’t г themselves Can ? with of users into Did

When users hold ERC7527 tokens, they can utilize the ERC6551 factory contract on the Ethereum mainnet to deploy an ERC6551 account for their ERC7527 tokens. Subsequently, they can use this ERC6551 account to interact with the ERC6551 bridging contract deployed on the mainnet. The bridging contract facilitates cross-chain interactions by invoking the ERC6551 factory contract on Ethereum Layer Two to deploy an ERC6551 account for the user on Layer Two.

The cross-chain implementation for ERC6551 has a straightforward approach, and developers can refer to the code within the ERC6551Mirror repository. This repository employs Chainlink CCIP to achieve cross-chain operations for ERC6551.

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

Atomic oracle

ERC7615 is an interesting ERC that defines a simple push protocol for atomic interactions between generic contracts. This straightforward push protocol can construct atomic oracles, significantly reducing the complexity of developing protocols such as lending agreements. The operational principle of ERC7615 is as follows:

When a user (Client) invokes certain functions on the sending contract (Publisher), the sending contract checks if there are any subscribing contracts. If they exist, it calls the exec function on the subscribing contract to push some content. The main feature of this process is atomicity. If the subscribing contract encounters issues processing the pushed data, the transaction calling the push contract’s function (i.e., the Call somefunc(…) transaction in the diagram) will directly error out.

In ERC7527, we have mentioned several times that the sell price provided by ERC7527 is effectively the liquidation price. Any holder of ERC7527 tokens can withdraw liquidity from the Agency at this sell price. Therefore, can we push ERC7527’s sell price to lending protocols to implement liquidation within the lending protocol?

The answer is yes. Moreover, due to the property of the continuous pricing model where sell prices increase macroscopically with the increase in ERC7527 holdings, lending protocols do not need to concern themselves with ERC7527 wrap operations, but only with unwrap transactions that could lead to price decreases.

We can embed ERC7615 push notifications within the unwrap function, directly pushing the current sell price of the unwrapped ERC7527 tokens to the lending protocol. When the lending protocol receives the push notification with the unwrap price, it can liquidate positions collateralized with ERC7527 tokens based on this pricing information.

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

Excitingly, the above operations are atomic. If the liquidation fails within the lending protocol, the unwrap operation of ERC7527 will also fail. This means the lending protocol completely avoids the risk of defaulting.

In fact, any protocol can obtain its sell price push notifications from ERC7527. This means developers only need to implement an ERC7615 receiver interface to obtain asset pricing and further complete other operations.

Within ERC7527, because ERC7527 tokens inherit from ERC721 on the contract level, developers can empower ERC7527 tokens in other ways. When users use traditional pledge schemes, such as directly transferring ERC7527 to a pledging contract, they lose other rights associated with ERC7527 tokens. Therefore, ERC7527 tokens need a new pledge scheme that does not require asset transfers.

Based on the push mechanism of ERC7615, such a pledge scheme can be designed. Specifically, establish a push relationship between the unwrap function in the ERC7527 Agency contract and the pledging contract. Pledging users can interact with the ERC7527 pledging contract to pledge ERC7527 tokens without transferring them to the pledging contract.

At this point, ERC7527 tokens can receive dividends from the pledging contract. When users unwrap their pledged ERC7527 tokens, the Agency contract uses ERC7615 to push this message to the pledging contract, which then releases the pledged status of the specified ERC7527 tokens and completes the final liquidation.

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

Disclaimer：

1. This article is reprinted from [PANews]. All copyrights belong to the original author [区块链骑士]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.