Stable processing method for double-token system

Abstract

The invention discloses a double-token system stabilization processing method, and the method comprises the steps: determining a weight change value of a candidate anchoring asset according to a stability change parameter and a price fluctuation change parameter of the candidate anchoring asset; determining a second weight value of the candidate anchoring assets at the current moment according to the weight change value of the candidate anchoring assets; and the target anchoring assets at the current moment are determined, and dynamic switching of the anchoring assets is realized. Determining the comprehensive anchor price of the system according to the respective asset price and the respective second weight value of each candidate anchor asset; according to the system comprehensive anchor price and the time weighted average price, determining the reverse gradient of the stability deviation, and determining the change value of the arbitrage mechanism parameter according to the reverse gradient of the stability deviation; determining a second arbitrage mechanism parameter at the current moment; and performing arbitrage excitation according to the second arbitrage mechanism parameter. Therefore, the problem that the stable currency is out of anchor due to invalidation of the arbitrage mechanism when the confidence of the related technology market is collapsed is solved.

Description

Technical Field

[0001] This application relates to the field of dual-token system technology, and in particular to a method for stabilizing a dual-token system. Background Technology

[0002] In this related technology, the stablecoin S in the dual-token system is pegged to 1 USD (US dollar stablecoin), but it is not fully collateralized. Instead, it relies on market arbitrage mechanisms and the assistance of the governance coin G to maintain its price. If S < 1 USD (indicating stablecoin depreciation), the supply of S needs to be reduced / demand increased; if S > 1 USD (indicating stablecoin appreciation), the supply of S needs to be increased / demand decreased. The core idea of ​​the arbitrage mechanism is that when S deviates from 1 USD, the system allows users to exchange it within the protocol at the pegged price (1 USD) and the free market price, thereby creating arbitrage and driving the price back to its normal level.

[0003] The problem with this technology is that if the value of the governance coin G drops sharply and market confidence is lost, the arbitrage mechanism may fail. In extreme cases (such as panic selling), arbitrage may not be able to absorb the shock in time, leading to the stablecoin de-pegging or even collapse. Summary of the Invention

[0004] This application provides a method for stabilizing a dual-token system to address the problem of stablecoin de-pegging caused by the failure of arbitrage mechanisms when market confidence in related technologies collapses.

[0005] Firstly, this application provides a method for stabilizing a dual-token system, the method comprising: For each candidate anchor asset, the weight change value of the candidate anchor asset is determined based on the stability change parameter and price fluctuation change parameter of the candidate anchor asset; the second weight value of the candidate anchor asset at the current time is determined based on the weight change value of the candidate anchor asset and the first weight value of the candidate anchor asset determined at the previous time; the target anchor asset at the current time is determined based on the second weight value of each candidate anchor asset. Based on the asset price and second weight value of each candidate anchor asset, a comprehensive system anchor price is determined; based on the comprehensive system anchor price and the time-weighted average price, a reverse gradient for stability deviation is determined; based on the reverse gradient for stability deviation, the change value of the arbitrage mechanism parameter is determined; based on the change value of the arbitrage mechanism parameter and the first arbitrage mechanism parameter determined at the previous moment, a second arbitrage mechanism parameter is determined at the current moment; arbitrage incentives are applied based on the second arbitrage mechanism parameter.

[0006] The above technical solution has the following advantages or beneficial effects: This application addresses the issue that related technologies using a fixed fiat currency (such as USD) as an anchor can easily lead to a single dependence when the macroeconomic market environment or fiat currency system fluctuates. It proposes a scheme to dynamically adjust the anchor weight based on market conditions, thereby dynamically adjusting the anchor asset. Specifically, based on the stability and price fluctuation parameters of the candidate anchor assets, the weight change value of the candidate anchor assets is determined; based on the weight change value of the candidate anchor assets, a second weight value of the candidate anchor assets at the current moment is determined; based on the second weight value of each candidate anchor asset, the target anchor asset at the current moment is determined, realizing dynamic switching of the anchor asset. This application maintains currency value stability through automatic re-anchoring, achieving "multi-anchor dynamic fault tolerance" and enhancing system robustness and long-term reliability. This application also addresses the problem that related arbitrage mechanisms rely on fixed arbitrage mechanism parameters (such as a 1:1 exchange rate, fixed cooldown time, etc.), making it difficult to adapt to market changes. It proposes a scheme to dynamically optimize arbitrage incentive parameters based on historical market performance and volatility characteristics. Specifically, the system's overall anchor price is determined based on the asset price and second weight value of each candidate anchor asset. The reverse gradient of stability deviation is determined based on the overall anchor price and the time-weighted average price. The change in arbitrage mechanism parameters is then determined based on this reverse gradient. The second arbitrage mechanism parameters for the current moment are determined based on these changes. Arbitrage incentives are then applied based on these second arbitrage mechanism parameters. By introducing self-learning parameter adjustment, the system can dynamically adjust arbitrage incentives according to market behavior, achieving a feedback game equilibrium. This prevents excessive speculation while ensuring sufficient incentives during de-anchoring. This addresses the problem of arbitrage mechanism failure and stablecoin de-anchoring caused by a collapse in market confidence in related technologies, thus strengthening the stability of the dual-token system.

[0007] Secondly, this application provides a dual-token system stabilization processing apparatus, the apparatus comprising: The dynamic anchoring module is used to determine the weight change value of each candidate anchoring asset based on the stability change parameter and price fluctuation change parameter of the candidate anchoring asset; determine the second weight value of the candidate anchoring asset at the current time based on the weight change value of the candidate anchoring asset and the first weight value of the candidate anchoring asset determined at the previous time; and determine the target anchoring asset at the current time based on the second weight value of each candidate anchoring asset. The dynamic arbitrage module is used to determine the system's comprehensive anchor price based on the asset price and second weight value of each candidate anchor asset; determine the reverse gradient of stability deviation based on the system's comprehensive anchor price and the time-weighted average price; determine the change value of the arbitrage mechanism parameters based on the reverse gradient of stability deviation; determine the second arbitrage mechanism parameters at the current time based on the change value of the arbitrage mechanism parameters and the first arbitrage mechanism parameters determined at the previous time step; and provide arbitrage incentives based on the second arbitrage mechanism parameters.

[0008] Thirdly, this application provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, used to execute a program stored in memory, implements the method described.

[0009] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described herein.

[0010] Fifthly, this application provides a computer program product comprising an executable program that is executed by a processor to implement the method described. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A schematic diagram illustrating the first type of dual-token system stabilization process provided in this application; Figure 2 This application provides a schematic diagram of the first type of mortgage pool repurchase process; Figure 3 A schematic diagram of the dynamic mortgage-to-value ratio adjustment process provided for this application; Figure 4 A schematic diagram illustrating the stabilization process of the second dual-token system provided in this application; Figure 5 This application provides a schematic diagram of the second type of collateral pool repurchase process; Figure 6 A schematic diagram of the casting process under normal conditions provided in this application; Figure 7A schematic diagram of the redemption process under normal conditions provided for this application; Figure 8 A schematic diagram of the structure of the dual-token system stabilization processing device provided in this application; Figure 9 A schematic diagram of the electronic device structure provided in this application. Detailed Implementation

[0013] To make the objectives and implementation methods of this application clearer, the exemplary implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings of the exemplary embodiments of this application. Obviously, the exemplary embodiments described are only some embodiments of this application, and not all embodiments.

[0014] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0015] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0016] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0017] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0018] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0019] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the embodiments and various different variations of embodiments suitable for specific application considerations.

[0020] The basic mechanism of the dual-token system is introduced as follows: In the dual-token model, the stablecoin S is pegged to 1 USD, but it is not fully collateralized. Instead, it relies on market arbitrage mechanisms and the assistance of the governance coin G to maintain its price.

[0021] If S < 1 USD (stablecoin depreciation) → the supply of S needs to be reduced / demand increased; If S > 1 USD (stablecoin appreciation) → the supply of S needs to be increased / demand decreased. The core idea of ​​arbitrage mechanism: When S deviates from 1 USD, the system allows users to exchange it at the anchor price (1 USD) and the free market price within the agreement, thereby creating arbitrage and driving the price back to its original level.

[0022] The following explains situations where the stablecoin price is below 1 USD (e.g., S = 0.9 USD): Target: Back to 1 USD; process: Users buy S stablecoins for 0.9 USD on the market (because it's cheaper than 1 USD). These stablecoins S are handed over to the protocol, and the system destroys the S and mints the governance coin G. The protocol's default exchange rate is 1 S = 1 USD equivalent of G; The user immediately receives the equivalent of 1 USD in G, while his cost is only 0.9 USD → arbitrage profit of 0.1 USD; S is destroyed, supply decreases, scarcity increases → pushing up the market price of S.

[0023] Result: The market price of S gradually recovered from 0.9 to 1.0 USD.

[0024] The following explains situations where the stablecoin price is higher than 1 USD (e.g., S = 1.1 USD): Target: Back to 1 USD; process: Users can mint 1 stablecoin S using 1 USD equivalent of governance token G within the protocol; Users spend 1 USD to obtain one stablecoin S; Sell ​​the S immediately on the market to gain USD 1.1. Arbitrage profit = USD 0.1; The increased market supply of stablecoin S has driven its price down.

[0025] Result: The market price of S gradually fell from 1.1 to 1.0 USD.

[0026] The core arbitrage logic is as follows: When S < 1 USD → User buys S → delivers it to the protocol for G → destroys S → reduces supply → drives up price; When S > 1 USD → User exchanges G for S in the protocol → sells S → increases supply → drives down price.

[0027] The system does not rely on a "centralized reserve," but instead automatically balances supply and demand through market arbitrage to maintain S = 1 USD.

[0028] The actual risks associated with arbitrage mechanisms are: If the value of the governance coin G drops sharply, market confidence will be lost, and the arbitrage mechanism may fail. In extreme cases (such as panic selling), arbitrage may not be able to absorb the shock in time, leading to the stablecoin de-pegging or even collapse.

[0029] Traditional dual-token models (StableToken + GovernToken) are prone to entering a "death spiral" when market confidence collapses, lacking external guarantees, multi-level responses, and dynamic strategies. This application aims to improve anchoring stability and system robustness by introducing hybrid collateralization, dual-layer protection (market arbitrage, collateral pool buyback), dynamic collateral ratio, and three innovative modules, while retaining algorithmic supply regulation and decentralized characteristics.

[0030] This application proposes an improved dual-token stablecoin system, introducing two layers of protection mechanisms: (1) Level 1: Market arbitrage – when there is a slight deviation, arbitrageurs are incentivized to restore the peg through a clear on-chain redemption / minting path; (2) Level 2: Collateral pool buyback – when there is insufficient arbitrage or a moderate deviation, the protocol actively uses external collateral assets to buy back and destroy stablecoins in the market to reduce supply. Simultaneously, a dynamic collateral ratio (DCR) is introduced, dynamically adjusting the external collateral ratio based on volatility, price deviation, and liquidity depth to balance efficiency and security.

[0031] The key terms used in this application are explained below: Stablecoin (S): A cryptocurrency pegged to a fiat currency (such as the US dollar USD) for use as a store of value, payment, and settlement. The goal is to maintain a stable price of 1 S ≈ 1 USD.

[0032] Governance Token (G): A secondary token issued by the system, used for governance voting, value capture, and arbitrage intermediaries in the stability mechanism. When the stablecoin deviates from its peg, the governance token and the stablecoin can be exchanged to correct the price.

[0033] Arbitrage Mechanism: This refers to the process by which users buy and sell when the market price differs from the system's exchange rate, thereby driving the stablecoin price back to its peg.

[0034] Collateral Pool: A pool of funds consisting of external assets (such as BTC, ETH, USDT) used to execute stablecoin buybacks or issuances when the arbitrage mechanism fails, in order to enhance system stability.

[0035] Dynamic Collateral Ratio (DCR): A mechanism that automatically adjusts the proportion of collateralized assets based on market volatility and the price of the governance token. The DCR increases during periods of high volatility to enhance security and decreases during periods of market stability to improve capital efficiency.

[0036] Peg Price: The target price (usually 1 USD) for a stablecoin, which serves as the benchmark for price adjustments.

[0037] Depeg: refers to the phenomenon where the market price of a stablecoin deviates significantly from its target peg (e.g., below 0.95 USD or above 1.05 USD).

[0038] Figure 1 The schematic diagram of the first dual-token system stabilization process provided in this application includes the following steps: S101: For each candidate anchor asset, determine the weight change value of the candidate anchor asset based on the stability change parameter and price fluctuation change parameter of the candidate anchor asset; determine the second weight value of the candidate anchor asset at the current moment based on the weight change value of the candidate anchor asset and the first weight value of the candidate anchor asset determined at the previous moment; determine the target anchor asset at the current moment based on the second weight value of each candidate anchor asset. S102: Determine the system's overall anchor price based on the asset price and second weight value of each candidate anchor asset; determine the reverse gradient of stability deviation based on the system's overall anchor price and the time-weighted average price; determine the change value of the arbitrage mechanism parameters based on the reverse gradient of stability deviation; determine the second arbitrage mechanism parameters at the current time based on the change value of the arbitrage mechanism parameters and the first arbitrage mechanism parameters determined at the previous time step; and implement arbitrage incentives based on the second arbitrage mechanism parameters.

[0039] The dual-token system stabilization method provided in this application is applied to electronic devices, such as personal computers (PCs), smart terminals, computers, servers, etc.

[0040] For each candidate pegged asset, the weight change value of the candidate pegged asset is determined based on the stability change parameter and price volatility change parameter of the candidate pegged asset. The candidate pegged assets refer to assets such as US Dollar (USD), Bitcoin (BTC), and Ethereum (ETH).

[0041] The stability change parameters of candidate anchor assets can be determined based on price stability, depth ratio, volatility penalty, and arbitrage health. Optionally, the result of calculating price stability + depth ratio - volatility penalty + arbitrage health can be used as the stability change parameters.

[0042] Combining time and market dimensions to determine price fluctuation parameters, taking USD as an example, the core calculation formula is as follows: \sigma_{USD} = \sqrt{ \frac{1}{N-1} \sum_{i=1}^{N} (P_i - \bar{P})^2} \quad \text{(standard deviation)}; P_i: The price at the i-th time point, used for fluctuation source data; \(\bar{P}\): Target anchor pricing, used to provide a benchmark value; N: Number of sampling points, used to balance sensitivity and noise; Δt: Sampling interval, used to capture fluctuations in different frequency bands.

[0043] The weight changes of the candidate anchor assets are determined based on their stability and price volatility parameters. Optionally, the weight changes of the candidate anchor assets can be determined using the formula α × (ΔSi - β × ΔVi), where Δsi is the stability parameter, Δvi is the price volatility parameter, and α and β are learning rate coefficients.

[0044] The sum of the weight change value of the candidate anchor asset and the first weight value of the candidate anchor asset determined at the previous moment is determined as the second weight value of the candidate anchor asset at the current moment.

[0045] Specifically, the second weight value for determining the candidate anchor asset at the current moment includes: The second weight value of candidate anchor asset i at the current time is determined according to the formula wi(t+1) = wi(t) + α × (ΔSi - β × ΔVi). In the formula, wi(t+1) is the second weight value of candidate anchor asset i at the current time, wi(t) is the first weight value of candidate anchor asset i determined at the previous time, Δsi is the stability change parameter, Δvi is the price fluctuation change parameter, and α and β are the learning rate coefficients.

[0046] The target anchor asset at the current moment is determined based on the second weight value of each candidate anchor asset; optionally, the candidate anchor asset corresponding to the largest second weight value is determined as the target anchor asset.

[0047] The dual-token system stabilization solution provided in this application includes a multi-anchor stable structure, an self-evolving arbitrage game mechanism (AGA), a liquidity bond mechanism (LDT), and dynamic collateral ratio intelligent control (DCR Adaptive Control).

[0048] Multi-anchor stable structure: By dynamically adjusting the weights of multiple anchors (USD, BTC, ETH, etc.), the anchor points can be switched adaptively, avoiding systemic de-anchoring caused by fluctuations in a single fiat currency.

[0049] This application proposes an algorithmic stablecoin system based on an "intelligent self-evolving feedback system," aiming to maintain long-term price stability in environments characterized by market volatility, confidence shocks, and multi-asset pegs. Building upon the existing dual-token model, the system retains two layers of protection logic: a "first-level arbitrage mechanism (Market Arbitrage)" and a "second-level collateral pool buyback mechanism (Collateral Buyback)," and introduces a meta-stability layer and an adaptive game arbitrage (AGA) module. The meta-stability layer enables variable anchor points and dynamic anchor weight adjustments; the adaptive game arbitrage module enables parameter self-learning and incentive self-adaptation.

[0050] The meta-stabilized layer is described below.

[0051] (1) Explanation of the principle: Traditional algorithmic stablecoins use a fixed fiat currency (such as USD) as an anchor, which can easily lead to a single dependence when the macroeconomic market environment or the fiat currency system fluctuates. The meta-stabilization layer of this application allows the system to dynamically switch or combine anchors based on market conditions, achieving "dynamic anchor weight adjustment (Peg Weight Adjustment)." Anchors can include USD, BTC, ETH, or other stable assets, and the system dynamically determines the current comprehensive anchor price (Peg) through a weight calculation formula. .

[0052] (2) Mathematical formula: Define the set of anchor points as: Assets = {USD, BTC, ETH, …}; System-wide anchor price calculation: Peg = Σ (wi × Pi); in: wi: The weight of the i-th anchored asset; Pi: The price of the asset relative to USD; Σ wi = 1.

[0053] Weight dynamic adjustment rules: wi(t+1) = wi(t) + α × (ΔSi - β × ΔVi); in: ΔSi represents the recent stability score change parameter of the asset; ΔVi represents the price fluctuation change parameter of the asset; α and β are learning rate coefficients.

[0054] When the volatility of a certain anchored asset (such as USD) increases or the risk of de-anchoring increases, the system automatically lowers its weight and increases the weight of BTC or ETH, thus achieving anchor migration.

[0055] (3) Engineering significance: This mechanism enables the system to maintain currency stability by automatically re-anchoring during macroeconomic events such as fiat currency fluctuations or the decoupling of the US dollar, achieving "multi-anchor dynamic fault tolerance" and enhancing the system's robustness and long-term reliability.

[0056] Based on the asset price and second weight value of each candidate anchor asset, a weighted summation algorithm is used to determine the system's overall anchor price. The back gradient for stability deviation is then determined based on the system's overall anchor price and the time-weighted average price. Optionally, the formula can be used... (- |TWAP- Peg) | ) / θ determines the reverse gradient of the stability bias. In the formula, TWAP is the time-weighted average price, and Peg... The system's overall anchor price is determined. The change in arbitrage mechanism parameters is determined based on the reverse gradient of the stability deviation. The second arbitrage mechanism parameters for the current time step are determined based on the sum of the change in arbitrage mechanism parameters and the first arbitrage mechanism parameters determined at the previous time step. Finally, arbitrage incentives are applied based on the second arbitrage mechanism parameters.

[0057] Specifically, the parameters for determining the second arbitrage mechanism at the current moment include: According to the formula θ(t+1) = θ(t) + η× (- |TWAP- Peg) | ) / θ determines the parameters of the second arbitrage mechanism at the current moment; In the formula, θ(t+1) represents the second arbitrage mechanism parameter at the current time, θ(t) represents the first arbitrage mechanism parameter determined at the previous time, TWAP represents the time-weighted average price, and Peg represents the price. η is the overall anchor price of the system, and η is the learning rate.

[0058] Self-evolving arbitrage game mechanism (AGA): Introducing reinforcement learning algorithm, it automatically optimizes incentive and cooling parameters based on historical arbitrage success rate and volatility characteristics, enabling the system's arbitrage behavior to have self-learning and self-adjusting capabilities.

[0059] The self-evolving arbitrage game mechanism is explained below.

[0060] (1) Explanation of the principle: Traditional arbitrage mechanisms rely on fixed parameters (such as a 1:1 exchange rate and a fixed cooldown time), making it difficult to adapt to market changes. This invention introduces a self-evolutionary learning logic to dynamically optimize arbitrage incentive parameters (reward rate, redemption fee rate, and cooldown time) based on historical market performance and volatility characteristics.

[0061] The objective function is: Minimize Var(TWAP - Peg) ); That is, to minimize the stablecoin price deviation variance over multiple periods, the system optimizes the parameter set θ = {r_arb (reward rate), fee_redeem (redemption fee rate), cooldown_time (cooldown time)} in reverse through the reward function.

[0062] (2) Parameter update formula: θ(t+1) = θ(t) + η × (- |TWAP- Peg) | ) / θ; Where: η is the learning rate; (- |TWAP- Peg) | ) / θ represents the reverse gradient of the stability deviation.

[0063] TWAP stands for Time-Weighted Average Price. It is a manipulation-resistant on-chain price calculation mechanism used to address the risks posed by instantaneous price fluctuations.

[0064] The system dynamically adjusts parameters based on the TWAP deviation within a historical window (e.g., the past N blocks): If TWAP deviates frequently, increase the arbitrage reward rate r_arb; if price fluctuations are excessive, increase the redemption fee rate or extend the cooldown period; if market volatility converges, gradually return to the benchmark value.

[0065] (3) Example explanation: Assuming the past 10 time windows: Mean Deviation | TWAP - Peg | = 0.03; Initial system parameters: r_arb = 0.02 (2%), fee_redeem = 0.001 (0.1%); Update magnitude calculation: Δr_arb = η × (|TWAP - Peg | - target_bias); Assume η = 0.2, target_bias = 0.01; Therefore, Δr_arb = 0.2 × (0.03 - 0.01) = 0.004; After the update: r_arb_next = 0.024 (increase reward to 2.4%).

[0066] (4) Engineering significance: By introducing self-learning parameter adjustment, the system can dynamically adjust arbitrage incentives based on market behavior, achieving a feedback game equilibrium. This prevents excessive speculation while ensuring sufficient incentives during de-anchoring. This mechanism endows the system with "behavioral self-adjustment," a core step in the evolution of algorithmic stablecoins into a smart economy.

[0067] This application implements stable processing of a dual-token system based on relevant contract components. These components include OracleManager, StableToken (ST), GovernToken (GT), CollateralPool, and MetaController.

[0068] OracleManager provides multi-asset TWAP, volatility, and anchor prices; StableToken (ST) is a stablecoin token; GovernToken (GT) is a governance and value absorption token; CollateralPool is an external collateral pool; MetaController is the core control contract, which includes DCR adjustment, anchor switching, arbitrage parameter learning, and bond issuance logic.

[0069] Each component describes its responsibilities and key interfaces (contract name + main functions).

[0070] 1. OracleManager: Functions: Collects price data from multiple sources, calculates TWAP (Time Weighted Average Price), and provides price / volatility / liquidity indicators.

[0071] Key methods: getTWAP(token, window) → returns price (USD); getVolatility(token, window) → returns realized volatilityσ; isStale() → boolean; The `getTWAP(token, window)` method retrieves the time-weighted average price, returning the average price in US dollars (USD) of a specified token (such as BTC / ETH) over a given time window. The `getVolatility(token, window)` function retrieves the volatility, returning the realized volatility (σ) of the token within the time window, which measures the risk of price fluctuations. isStale() checks if the data is outdated and returns a boolean value (true / false) to determine if the price data is expired or invalid.

[0072] 2. StableToken (ERC20): Features: Stablecoin base token, supports mint / burn (controller adjustable only).

[0073] 3. GovernToken (ERC20): Function: Governance / Equity Coin, through which the system absorbs volatility, distributes seigniorage, and provides incentives.

[0074] 4. Collateral Pool: Function: Hold external collateral assets (such as USDC, WETH, and other eligible collateral) for repurchase / redemption / resetting of collateral ratio.

[0075] Key methods: reserveValue() → USD value of collateral; withdrawForBuyback(amountUSD) → transfers collateral toMarketModule; depositCollateral(token, amount); reserveValue() retrieves the total value of collateral, calculating the real-time total USD value of all collateral assets (such as BTC / ETH) in the system; `withdrawForBuyback(amountUSD)` withdraws collateral for a buyback, transferring a specified USD value of collateral from the reserve pool to the MarketModule to execute a token buyback of the stablecoin price. `depositCollateral(token, amount)` deposits collateral, where users deposit a specified number of tokens and a specified amount as collateral for lending or protocols.

[0076] 5. MetaController: Function: Core policy execution, responsible for mint / redeem, adjusting DCR, triggering buyback, and managing quotas and cooldowns.

[0077] Key methods: mintStable(amountUSD, payerCollateral, payerGT) / / Accepts collateral and / or GT (contract component) minting; redeemStable(amountStable, receiver) / / Provides collateral + GT based on DCR; adjustDCR() / / Periodically or triggered by an event; triggerLevel(level) / / Manual / automatic trigger; State machine: NORMAL → ALERT (Level-1) → RECOVERY (Level-2) → NORMAL.

[0078] When performing dual-token stabilization, first deploy OracleManager, StableToken, GovernToken, CollateralPool, and MetaController on the blockchain; set initial parameters (DCR_target=0.4, threshold, etc.) and write timelock; deposit initial collateral (such as USDC) into CollateralPool; and reserve a portion of G as an early liquidity / minting pool.

[0079] This application addresses the issue that related technologies using a fixed fiat currency (such as USD) as an anchor can easily lead to a single dependence when the macroeconomic market environment or fiat currency system fluctuates. It proposes a scheme to dynamically adjust the anchor weight based on market conditions, thereby dynamically adjusting the anchor asset. Specifically, based on the stability and price fluctuation parameters of the candidate anchor assets, the weight change value of the candidate anchor assets is determined; based on the weight change value of the candidate anchor assets, a second weight value of the candidate anchor assets at the current moment is determined; based on the second weight value of each candidate anchor asset, the target anchor asset at the current moment is determined, realizing dynamic switching of the anchor asset. This application maintains currency value stability through automatic re-anchoring, achieving "multi-anchor dynamic fault tolerance" and enhancing system robustness and long-term reliability. This application also addresses the problem that related arbitrage mechanisms rely on fixed arbitrage mechanism parameters (such as a 1:1 exchange rate, fixed cooldown time, etc.), making it difficult to adapt to market changes. It proposes a scheme to dynamically optimize arbitrage incentive parameters based on historical market performance and volatility characteristics. Specifically, the system's overall anchor price is determined based on the asset price and second weight value of each candidate anchor asset. The reverse gradient of stability deviation is determined based on the overall anchor price and the time-weighted average price. The change in arbitrage mechanism parameters is then determined based on this reverse gradient. The second arbitrage mechanism parameters for the current moment are determined based on these changes. Arbitrage incentives are then applied based on these second arbitrage mechanism parameters. By introducing self-learning parameter adjustment, the system can dynamically adjust arbitrage incentives according to market behavior, achieving a feedback game equilibrium. This prevents excessive speculation while ensuring sufficient incentives during de-anchoring. This addresses the problem of arbitrage mechanism failure and stablecoin de-anchoring caused by a collapse in market confidence in related technologies, thus strengthening the stability of the dual-token system.

[0080] Figure 2 The first type of collateralized pool repurchase process provided for this application includes the following steps: S201: If the actual available balance in the current collateral pool is less than the amount of the redemption request initiated by the user, the face value of the bond shall be determined based on the redemption request amount and the collateral pool balance. S202: Determine the discount rate based on the total amount of stablecoins, bond supply, and bond face value; S203: Determine the market price of the liquid bond mechanism based on the bond's face value and discount rate, and redeem the bonds according to the market price.

[0081] The difference between the redemption request amount and the balance of the collateral pool is determined as the face value of the bond.

[0082] The discount rate is determined based on the total amount of stablecoins, the bond supply, and the bond face value, including: Substitute the total amount of stablecoins, bond supply, and bond face value into the formula discount = base_rate + γ × (LDT_nominal / total_supply_ST) to determine the discount rate; In the formula, discount is the discount rate, base_rate is the bond supply, LDT_nominal is the bond face value, total_supply_ST is the total amount of stablecoins, and γ is the preset risk coefficient.

[0083] The market price of a liquidity bond mechanism can be determined by calculating the difference between the bond face value and the discount rate, and then multiplying the bond face value by this difference to determine the market price of the liquidity bond mechanism.

[0084] In extreme market conditions, the collateral pool may experience temporary funding shortages, preventing the full redemption of stablecoins. While related technologies may directly suspend redemptions, this application addresses this issue through a "liquidity bond mechanism." This mechanism tokenizes the system's temporary debt, allowing liquidity risk to be diversified through the market and preventing a collapse in trust due to redemption freezes. Through market trading mechanisms, bonds can facilitate price discovery, thereby stabilizing expectations and absorbing shocks.

[0085] To prevent collateral collapse, this application also introduces a Liquidity Debt (LDT) module. The Liquidity Debt module is used to issue short-term bond tokens to absorb market liquidity shocks when the collateral pool is insufficient, forming a third layer of defense mechanism to prevent collateral collapse. In other words, it achieves delayed redemption and market self-repair through debt tokenization when there is a liquidity shortage.

[0086] The liquidity bond mechanism is explained below.

[0087] (1) Explanation of the principle: In extreme market conditions, the collateral pool may experience temporary funding shortages, preventing the full redemption of stablecoins. Traditional systems that directly suspend redemptions would damage confidence; this invention addresses this issue through a "liquidity bond mechanism."

[0088] When CollateralPool.available (the total amount of underlying assets actually available in the current collateral pool) < redeem_request_total (the total amount of batch redemption requests currently initiated by users), the system automatically issues "liquidity bonds" (LDT), recording the amount to be redeemed, the discount rate, and the maturity repurchase plan. LDT can be traded or used as collateral, and users can choose to wait for redemption or sell at a discount.

[0089] (2) Bond Pricing and Discount Calculation: Let the redemption request amount be X_USD and the collateral pool balance be Y_USD, then the bond face value: LDT_nominal = X_USD - Y_USD; Discount Rate Calculation: discount = base_rate + γ × (LDT_nominal / total_supply_ST); Where, total_supply_ST: the total number of stablecoins; base_rate: the bond supply; γ is a preset risk coefficient, and the discount increases when the system debt increases.

[0090] Example: [[ID=?]] X_USD = 1000, Y_USD = 800, LDT_nominal = 200; Assume base_rate = 0.05, γ = 0.1, LDT_supply / total_supply_ST = 0.2; discount = 0.05 + 0.1×0.2 = 0.07 (7% discount); LDT market price = 200 × (1 - 0.07) = 186 USD.

[0091] (3) Redemption Process (repurchase bonds at the LDT market price).

[0092] If the redemption is successful, the process ends; if it fails, proceed to the subsequent process: When the user's redemption fails, LDT is automatically generated and the maturity height (time limit) is recorded; LDT can be sold or used as collateral in the secondary market; The system automatically repurchases LDT after future seigniorage income, repurchase surplus, or new liquidity injection; After maturity, LDT is automatically destroyed and redeemed.

[0093] (4) Engineering significance: The LDT mechanism tokenizes systemic temporary debt, enabling market-based diversification of liquidity risk and preventing a collapse of trust due to redemption freezes. Through market trading mechanisms, bonds can undergo a price discovery process, thereby stabilizing expectations and absorbing shocks.

[0094] The meta-stabilization layer, the self-evolving arbitrage game module, and the liquid bond module, together with the dynamic collateral ratio (DCR) adjustment algorithm, constitute a complete intelligent stabilization closed loop, enabling the system to have self-learning, self-defense, and self-repair capabilities.

[0095] Figure 3 The schematic diagram of the dynamic mortgage-to-value ratio adjustment process provided for this application includes the following steps: S301: Determine market risk parameters based on price volatility, price deviation, liquidity depth, and their respective third weight values; S302: Determine the arbitrage behavior feedback parameters based on the current arbitrage return rate and the average historical arbitrage return rate; S303: Determine the multi-anchor weight migration parameters based on the preset change in the weight value of the primary anchor asset; S304: Determine bond supply adjustment parameters based on the current supply of liquid bonds, total collateral pool assets, and the target market price of the liquid bond mechanism; S305: Determine the collateral ratio adjustment value based on market risk parameters, arbitrage behavior feedback parameters, multi-anchor weight migration parameters, and bond supply adjustment parameters; S306: Determine the projected mortgage rate based on the current mortgage rate and the mortgage rate adjustment value.

[0096] Dynamic Collateral Ratio Intelligent Control (DCR Adaptive Control): Adjusts the collateral ratio in real time based on volatility, price deviation, and liquidity depth, and incorporates feedback from three innovative modules to form an intelligent closed-loop adjustment system, enabling the stablecoin system to achieve self-awareness and self-repair capabilities.

[0097] The market risk parameter is obtained by weighting and summing price volatility, price deviation, liquidity depth, and their respective third weight values. Preferably, price volatility, price deviation, and liquidity depth are normalized separately to obtain normalized price volatility, normalized price deviation, and normalized liquidity depth. Then, these normalized price volatility, normalized price deviation, and normalized liquidity depth are weighted and summed with their respective third weight values ​​to obtain the market risk parameter.

[0098] Based on the current arbitrage return and the average historical arbitrage return, determine the arbitrage behavior feedback parameters. Optionally, the difference between the current arbitrage return and the average historical arbitrage return can be used as the arbitrage behavior feedback parameter. More preferably, the product of the difference between the current arbitrage return and the average historical arbitrage return and a preset weight value corresponding to the arbitrage behavior can be used as the arbitrage behavior feedback parameter.

[0099] The multi-anchor weight migration parameter is determined based on the change in the weight value of the preset primary anchor asset. The preset primary anchor asset is, for example, USD. For instance, if the weight value of USD changes from 0.5 to 0.6, the change in the weight value of the primary anchor asset is 0.6 - 0.5 = 0.1. Preferably, the multi-anchor weight migration parameter is determined by multiplying the change in the weight value of the primary anchor asset by the preset weight value corresponding to the multi-anchor weight migration.

[0100] The bond supply adjustment parameters are determined based on the current supply of liquid bonds, total collateral pool assets, and the target market price of the liquid bond mechanism. Optionally, the ratio of the current supply of liquid bonds to the total collateral pool assets is determined, and the difference between this ratio and the target market price of the liquid bond mechanism is used as the bond supply adjustment parameter. Preferably, the difference between this ratio and the target market price of the liquid bond mechanism is determined, and then the product of this difference and a preset weight value corresponding to bond supply adjustment is used as the bond supply adjustment parameter.

[0101] Specifically, based on market risk parameters, arbitrage behavior feedback parameters, multi-anchor weight migration parameters, and bond supply adjustment parameters, the collateral ratio adjustment value is determined as follows: According to the formula club([k_vol) σ_norm + k_pr price_norm - k_liq depth_norm]+ [β1 ΔR_aga]+ [β2 ΔW_meta]+ [β3 (LDT_supply_ratio - LDT_target)] , -Δ, +Δ ), determine the mortgage ratio adjustment value; In the formula, clamp is the constraint function, σ_norm is the normalized price volatility, price_norm is the normalized price deviation, depth_norm is the normalized liquidity depth, k_vol, k_pr, and k_liq are the third weight values ​​corresponding to the normalized price volatility, normalized price deviation, and normalized liquidity depth, respectively, ΔR_aga is the difference between the current arbitrage return and the average historical arbitrage return, and β1 ΔR_aga is the arbitrage behavior feedback parameter, β2 ΔW_meta is the multi-anchor weight migration parameter, LDT_supply_ratio is the ratio of current liquid bond supply to total collateral pool assets, LDT_target is the target market price of the liquid bond mechanism, and β3 (LDT_supply_ratio - LDT_target) is the bond supply adjustment parameter, and β1, β2 and β3 are weight values.

[0102] The sum of the current mortgage rate and the mortgage rate adjustment value is used to determine the predicted mortgage rate.

[0103] The calculation process for the Dynamic Collateral Ratio (DCR) is explained below.

[0104] Dynamic collateral ratio (DCR) is designed to reduce DCR (improving capital efficiency) when the market is stable and increase DCR (enhancing security) when there is volatility / deep risk.

[0105] Defined metric: σ = realized volatility (σ represents the realized volatility over a past period (M days), i.e., the actual price fluctuation). If market volatility is high, it indicates greater risk → the system will automatically increase the collateral ratio (DCR) to enhance security. If market volatility is low, the system can decrease the DCR to improve capital efficiency.

[0106] Define the metrics: priceDev = abs(TWAP - 1) The absolute difference between the stablecoin price and its peg. The larger the deviation, the more the system needs to increase the collateral ratio to enhance hedging capabilities. When the deviation is close to 0 (TWAP ≈ 1), the system can maintain or reduce the collateral ratio. depth = liquidityDepthMetric (e.g., USD volume causing 1% slippage) Market liquidity depth metric. Measures how much capital (in USD) is needed in the market to cause a 1% slippage in price.

[0107] For example, if a trading volume of only 1,000,000 USD is enough to cause a 1% price fluctuation, it indicates poor liquidity (low depth); conversely, if it takes 50,000,000 USD to cause a 1% fluctuation, it indicates high liquidity (high depth). High liquidity means low systemic risk, which can reduce the DCR (Discretionary Rate of Return). Low liquidity means high systemic risk, which should be increased to improve stability.

[0108] Example parameter: DCR_target = 0.40.

[0109] Weights: k_vol = 0.5 (volatility weight, representing the system's sensitivity to "market volatility"), k_pr = 0.3 (price deviation weight, representing the system's sensitivity to "price deviation from anchor"), k_liq = 0.2 (liquidity depth weight, representing the system's sensitivity to "market liquidity"). DCR_min = 0.10, DCR_max = 0.80. Δ = 0.05 (maximum change per unit).

[0110] The dynamic collateral ratio (DCR) calculation steps are as follows: Step 1: Normalization.

[0111] σ_norm = normalize(σ, σ_floor, σ_ceil) → map to [0,1]; price_norm = normalize(priceDev, 0, priceCap) → [0,1]; depth_norm = normalize(depth, depthFloor, depthCap) → [0,1]; σ_norm (volatility normalization): σ_norm = (σ - σ_floor) / (σ_ceil - σ_floor); σ: Market volatility (e.g., ETH / USD 30-day annualized volatility); σ_floor / σ_ceil: Preset upper and lower bounds for volatility (e.g., 0.2~1.0).

[0112] Compressing the actual volatility to [0,1], excessively high volatility approaches 1.

[0113] price_norm (price deviation normalization): price_norm = min(priceDev / priceCap, 1.0); priceDev: |TWAP - 1| (the absolute value of the deviation of stablecoin S from USD); priceCap: Maximum tolerance deviation (e.g., 0.1 = 10%). The more severe the price decoupling, the greater the value.

[0114] depth_norm (liquidity depth normalization): depth_norm = (depth - depthFloor) / (depthCap - depthFloor); depth: Total real-time liquidity of the DEX's S / USDC pool (in USD). depthFloor / depthCap: Liquidity warning range (e.g., 5M). The more depleted the liquidity, the larger the value.

[0115] Step 2: Calculate candidate values.

[0116] candidate = DCR_target + k_vol σ_norm + k_pr price_norm - k_liq depth_norm.

[0117] Step 3: Limiting and cooling.

[0118] To achieve system self-adaptation, anti-manipulation, and risk prediction capabilities, this invention extends the original linear dynamic collateral ratio (DCR) adjustment algorithm, upgrading it from a single market indicator response model to a multi-layer feedback self-evolutionary control system.

[0119] DCR_next = DCR_prev + clamp(

[0120] [k_vol σ_norm + k_pr price_norm - k_liq depth_norm] / / f1 Market Risk Layer + [β1 ΔR_aga] / / f2 Arbitrage behavior feedback layer

[0121] + [β2 ΔW_meta] / / f3 Multi-anchor weight transfer layer

[0122] + [β3 (LDT_supply_ratio - LDT_target)] / / f4 Bond supply adjustment layer, -Δ, +Δ); in: ΔR_aga = Current arbitrage return - Average historical return; ΔW_meta = Change in the weight of the main anchor (USD) (e.g., 0.6 → 0.5); LDT_supply_ratio = Current supply of liquid bonds / Total collateral pool assets; The coefficients β1 to β3 are determined by the governance layer (similar to extended weights) and work in parallel with the original weights k_vol, k_pr, and k_liq.

[0123] This extended formula upgrades the original linear static collateral ratio adjustment algorithm to a multi-layer adaptive feedback control system: f1 retains the traditional economics foundation (supply and demand + risk).

[0124] f2~f4 introduce game feedback, structural migration and debt absorption mechanisms, enabling DCR to learn dynamically based on the system state.

[0125] The system has evolved from a "passive defensive" system to a "predictive" defensive system.

[0126] Table 1. Parameters for f1-f4

[0127] In this application, before determining the weight change value of each candidate anchor asset based on its stability change parameter and price fluctuation change parameter, the method further includes: Within the historical sampling time window, if the time-weighted average price is less than the preset first price threshold for the first consecutive number of times, the process is to determine the weight change value of each candidate anchor asset based on the stability change parameter and price fluctuation change parameter of the candidate anchor asset.

[0128] Figure 4 The schematic diagram of the second dual-token system stabilization process provided in this application includes the following steps: S401: Within the historical sampling time window, if the time-weighted average price is less than the preset first price threshold for a first number of consecutive times, for each candidate anchor asset, determine the weight change value of the candidate anchor asset based on the stability change parameter and price fluctuation change parameter of the candidate anchor asset; determine the second weight value of the candidate anchor asset at the current time based on the weight change value of the candidate anchor asset and the first weight value of the candidate anchor asset determined at the previous time; determine the target anchor asset at the current time based on the second weight value of each candidate anchor asset. S402: Determine the system's overall anchor price based on the asset price and second weight value of each candidate anchor asset; determine the reverse gradient of stability deviation based on the system's overall anchor price and the time-weighted average price; determine the change value of the arbitrage mechanism parameters based on the reverse gradient of stability deviation; determine the second arbitrage mechanism parameters at the current time based on the change value of the arbitrage mechanism parameters and the first arbitrage mechanism parameters determined at the previous time step; and implement arbitrage incentives based on the second arbitrage mechanism parameters.

[0129] In this application, if the actual available balance in the current collateral pool is less than the amount of the redemption request initiated by the user, before determining the face value of the bond based on the redemption request amount and the collateral pool balance, the method further includes: Within the historical sampling time window, if the time-weighted average price is less than the preset second price threshold for the second consecutive number of times; or if the collateral pool balance is less than the preset safety threshold, the process of determining the bond face value based on the redemption request amount and the collateral pool balance will be carried out if the actual available collateral pool balance is less than the amount of the redemption request initiated by the user.

[0130] Figure 5 The second type of collateral pool repurchase process provided for this application includes the following steps: S501: Within the historical sampling time window, if the time-weighted average price is less than the preset second price threshold for the second consecutive number of times; or if the collateral pool balance is less than the preset safety threshold, and if the actual available collateral pool balance in the current collateral pool is less than the amount of the redemption request initiated by the user, the face value of the bond shall be determined based on the redemption request amount and the collateral pool balance. S502: Determine the discount rate based on the total amount of stablecoins, bond supply, and bond face value; S503: Determine the market price of the liquid bond mechanism based on the bond's face value and discount rate, and redeem the bonds according to the market price.

[0131] In this application, the method also includes: Once the system is in its initial, normal state; or once the time-weighted average price recovers to the preset range and liquidity rebounds, it switches back to the normal state. Figure 6 The schematic diagram provided in this application illustrates the casting process under normal conditions, which includes the following steps: S601: The user initiates a minting request, which includes the target amount of stablecoin to be minted, an array of collateral token types, and the number of governance tokens. S602: If the time-weighted average price is normal, obtain the collateralization ratio and calculate the asset requirement based on the collateralization ratio; the asset requirement includes the value of the required collateral and the value of the governance tokens to be burned; S603: Transfer collateralized tokens to the collateral pool, burn governance tokens to the treasury, and mint and distribute stablecoins to user addresses.

[0132] The user calls `Controller.mintStable(amountUSD, collateralTokens[], gtProvided)`. The user initiates a minting request by calling the function: `Controller.mintStable(amountUSD, collateralTokens[], gtProvided)`. `amountUSD` is the target amount of stablecoin to be minted (in USD); `collateralTokens[]` is an array of collateral token types provided by the user (e.g., [ETH, BTC]); `gtProvided` is the amount of governance tokens provided by the user. The contract checks if `Oracle.getTWAP(window)` is abnormal (to prevent manipulation); if TWAP is abnormal, the transaction is rejected or the minting amount is limited. The contract calls `Oracle.getTWAP(window)` to obtain the time-weighted average price. Risk control logic: If TWAP is abnormal (e.g., deviating from the threshold ±5%), the transaction is rejected or the minting amount is limited (to prevent price manipulation). The dynamic collateral ratio `DCR_t = currentDCR()` is read. Calculate the current system's required dynamic collateral ratio: DCR_t = currentDCR(); Meaning of DCR_t: Value range example: DCR_t = 0.8 means that 80% of the assets need to be collateralized and 20% of the governance tokens need to be burned.

[0133] Calculation: collateralNeededUSD = amountUSD DCR_t Required collateral value (USD); gtNeededUSD = amountUSD (1 - DCR_t) The value of the governance tokens (USD) to be burned. If the user provides sufficient collateral and / or GT, the transfer is completed, and a mint fee is charged. Check that the total value of the user-provided collateralTokens[] is greater than or equal to collateralNeededUSD and the value of gtProvided is greater than or equal to gtNeededUSD. Transfer the collateral tokens to the CollateralPool; burn the governance tokens to the Treasury; optional: charge a mint fee proportionally. Execute S.mint(user, amountUSD_in_ST); add collateral to the pool, or consume GT to the Treasury. Call the function: S.mint(user, amountUSD_in_ST), minting and distributing stablecoins to the user's address.

[0134] Figure 7 The diagram provided for this application illustrates the redemption process under normal conditions, which includes the following steps: S701: A user initiates a redemption request, which includes the amount of stablecoins to be destroyed, the minimum amount of collateral output, and the minimum amount of governance tokens to be output. S702: Obtain the collateralization ratio and the total value of the collateral pool, and calculate the assets to be returned based on the collateralization ratio; wherein, the assets to be returned include the value of the collateral to be returned and the value of the governance tokens to be returned; S703: If the collateral pool funds meet the redemption requirements, transfer collateral of equal value from the collateral pool to the user, and transfer governance tokens of equal value to the user from the treasury; otherwise, proceed with the bond redemption process. The bond redemption process is as follows: Figure 2 The process is shown.

[0135] The user calls `Controller.redeemStable(amountS, minCollateralOut, minGTOut)`. The user initiates a redemption request by calling the function: `Controller.redeemStable(amountS, minCollateralOut, minGTOut)`. `amountS` is the amount of stablecoins the user wants to destroy; `minCollateralOut` is the minimum acceptable amount of collateral output (anti-slippage protection); `minGTOut` is the minimum acceptable amount of governance tokens output. The contract reads `DCR_t` and `CollateralPool.reserveValueUSD()`. The contract obtains the dynamic collateral ratio in real time: `DCR_t = currentDCR()`; the total value of the collateral pool: `CollateralPool.reserveValueUSD()` (calculated via `reserveValue()`).

[0136] Calculate collateralOut = amountS DCR_t (the value of the collateral to be returned (USD)) and gtOutValue = amountS (1 - DCR_t) (Value of governance tokens to be returned (USD)). If the CollateralPool has enough available collateral, immediately transfer collateral and mint / transfer GT to the user; otherwise: in NORMAL: it can enter a partial redemption queue (installment redemption) or allow the user to choose GT-only redemption. If insufficient and the triggering condition is met, the Controller switches to RECOVERY (Level-2) and executes according to the buyback process.

[0137] The parameters, default values, and parameter descriptions involved in the dual-token system stability processing method provided in this application are shown in Table 2 below.

[0138] Table 2 Key Parameters

[0139] The triggering logic for the stabilization process of the dual-token system provided in this application is explained as follows: Step 1: Entering the Initial State: NORMAL. In the initial state, the system operates smoothly, the stablecoin price (monitored via Oracle.TWAP) is within the target range (≈$1), and the collateral pool balance is sufficient. The metrics monitored in the initial state include: Oracle.TWAP: Time-weighted average price, reflecting the real-time market price of stablecoins.

[0140] CollateralPool Balance: The total value of collateral (such as BTC / ETH) in the system (obtained via reserveValue()).

[0141] Step 2: If Oracle.TWAP falls below the preset threshold Level1_threshold for N1 consecutive times, an alert is triggered, initiating Level-1 protection (arbitrage mechanism). N1 is the preset number of consecutive occurrences (e.g., N1=3) to avoid false triggering due to short-term fluctuations. The purpose of this step is to provide early warning and prevent further price decoupling.

[0142] The process of Level-1 protection (ALERT) is explained below.

[0143] Level-1 refers to arbitrage (ALERT) – an open (automated) on-chain redemption path. Level-1 aims to enable explicit and verifiable 1:1 equivalent exchanges, allowing arbitrageurs to capture risk-free price differences, thereby reducing or increasing the supply of S (depending on the direction).

[0144] Level-1 includes the following steps: Oracle detects TWAP < Level1_threshold N1 times consecutively → ControllertriggerLevel(1) → switches to ALERT and opens the arbRedeem interface on-chain (or directly opens redeemStable). Oracle detecting TWAP < Level1_threshold N1 times consecutively indicates that the stablecoin (S) price has de-pegged. The controller triggers triggerLevel(1) to enter the ALERT state. Opening the arbitrage interface: Opening arbRedeem on-chain (or directly enabling redeemStable) allows external intervention.

[0145] arbRedeem explicitly defines the exchange rules in the contract: for example, 1 S → collateralOut + GT_out (calculated based on the current DCR value).

[0146] Where: collateralOut = value of collateralized assets (calculated at real-time price); GT_out = protocol governance token (used to cover the gap, calculated at the DCR discount rate).

[0147] Arbitrageurs buy S on the DEX at the market price P_market (if P_market < 1), then call arbRedeem to transfer S to the protocol and receive a combination (collateral + GT) worth USD, thus realizing the arbitrage. If the DEX market price P_market < 1, the arbitrageur buys S at a lower price. Calling arbRedeem to redeem from the protocol: Input: 1S; Output: a combination of (collateral + GT) worth 1 USD.

[0148] The Controller monitors the CollateralPool balance. If the balance falls below a safety threshold or TWAP fails to recover within a specified window, it switches to RECOVERY mode. Monitoring metrics: CollateralPool balance falls below the safety threshold; TWAP fails to recover to the anchor price within the T_recovery time window. Controller response: Switches to RECOVERY state.

[0149] Step 3: If the ALERT state persists and TWAP does not recover (e.g., TWAP remains below Level1_threshold for more than a preset time) or the CollateralPool balance drops to the safety threshold, RECOVERY (Level-2) is triggered. This activates the emergency recovery strategy, the core of which is executing the `withdrawForBuyback(amountUSD)` function to extract assets from the collateral pool to repurchase stablecoins. The repurchase logic involves burning the repurchased stablecoins, reducing the supply to drive up the price. The safety threshold is calculated in real-time using `reserveValue()`, based on the lower limit of collateral coverage preset by governance.

[0150] Level-2 refers to the protocol buyback (RECOVERY) – CollateralPool actively buys back and destroys S. The triggering conditions are: Level-1 fails to recover for a continuous period of time, or TWAP < Level2_threshold for N2 consecutive times, or the collateral pool reserves CollateralPool.reserveValueUSD() fall below the safety threshold (e.g., below 20% of the target).

[0151] Level-2 includes the following steps: The controller calculates the repurchase budget for this round: budgetUSD = min(CollateralPool.reserveValueUSD() buyback_budget_ratio, maxBuybackPerEpoch); for example budgetUSD = CollateralPool 0.25.

[0152] `budgetUSD` represents the budget amount for this round of buybacks (in USD), which is the upper limit of funds the protocol plans to use to buy back stablecoin S. `CollateralPool.reserveValueUSD()` is the current total reserve value of the collateral pool (in USD). This is a function call that retrieves the total value of collateral assets (such as USDC and WETH) in the pool in real time. `buyback_budget_ratio` is a preset buyback budget ratio (e.g., 0.25 represents 25%) used to calculate the proportion of the budget to the collateral pool value. `maxBuybackPerEpoch` is the maximum buyback amount allowed per epoch to prevent excessive consumption of pool funds. `min(...)` is a function that takes the minimum value to ensure that the final budget does not exceed the limit of `maxBuybackPerEpoch` (e.g., if the calculated value exceeds the upper limit, the upper limit value is used).

[0153] The Controller calls `CollateralPool.withdrawForBuyback(budgetUSD)` to transfer the corresponding assets (USDC / WETH) to the MarketModule. Controller: The core control module (smart contract) of the protocol, responsible for state machine switching, parameter calculation, and cross-module scheduling. `.withdrawForBuyback()`: A function name in the `CollateralPool` contract that extracts a specified amount of assets from the collateral pool, specifically for buyback operations. `budgetUSD`: An input parameter (unit: USD), declaring the amount of funds to be withdrawn for this buyback (calculated and determined in step 1). `CollateralPool`: A reserve pool contract that stores the protocol's collateral assets (such as USDC, WETH), holding user collateral and ensuring the value support of the stablecoin S. Corresponding assets (USDC / WETH): The actual type of asset being withdrawn, prioritizing the withdrawal of highly liquid stable assets (such as USDC), and exchanging for other assets (such as WETH) according to a preset ratio if insufficient. Transfer to MarketModule: The asset transfer path transfers the withdrawn assets to the MarketModule contract (responsible for on-chain transaction execution).

[0154] The MarketModule executes step-by-step buying in predetermined markets (such as the Uniswap path or centralized order book), splitting budgetUSD into n segments (segmented orders), with each segment placed at TWAP or as a limit order to reduce market impact. MarketModule: A smart contract module dedicated to on-chain transactions. Uniswap path: Transaction via an Automated Market Maker (AMM) (such as the S / USDC trading pair); Centralized order book: Such as the on-chain interface of Coinbase Pro (requires oracle support). Step-by-step buying: n segments: Dividing the total budget into multiple small transactions to avoid large orders instantly driving down the price; TWAP order: Executing transactions in batches based on the time-weighted average price, simulating institutional trading strategies and reducing price volatility; Limit order: Setting an acceptable maximum buy price to prevent slippage losses from exceeding the budget.

[0155] Each time S is purchased, it is immediately transferred to the Controller and burned. S is transferred to the Controller in real-time after each purchase (temporary storage is prohibited to prevent attacks). The burn() function is then called to permanently destroy the S tokens. Impact: Circulating supply decreases → increases the collateral support ratio of remaining tokens; the burned data is written to the blockchain (immutable).

[0156] Update CollateralPool and totalBurned, and record the BuybackExecuted event. CollateralPool.update(): deducts the used budget amount; totalBurned: the total historical burn amount; BuybackExecuted event(): records the budget amount, average actual purchase price, burn amount, and timestamp.

[0157] After the buyback is complete, the Controller rereads Oracle.TWAP: if TWAP recovers to [1-ε, 1+ε], switch back to NORMAL; (with the target anchor price of 1 USD as the center, allowing fluctuations of ε (epsilon, tolerance)). If it still does not recover, another buyback round can be performed with governance permission (until the budget is exhausted or governance is paused).

[0158] Step 4: Execute a buyback strategy in RECOVERY. If TWAP recovers to [1-ε, 1+ε] and liquidity improves, switch back to NORMAL. ε is a preset value (e.g., ε=0.005, meaning the price is between $0.995 and $1.005). Liquidity improvement means that stablecoin trading volume or collateral pool balance has returned to a safe level (verified by on-chain data). At this point, automatically exit RECOVERY state and stop buyback operations. Resume normal business (e.g., allowing users to deposit collateral and borrow). ε preset value: The tolerance deviation set by governance (usually ε ≤ 0.01) to ensure price stability within a practical range.

[0159] Step 5: All critical migrations are recorded as on-chain events and can be paused via multisigning / governance. On-chain events include all state transitions (e.g., NORMAL → ALERT) and critical operations (e.g., buybacks), ensuring transparency and auditability. Multisigning / Governance Pause: The governance committee can pause automatic state transitions via multisigning wallets or voting (e.g., manually freezing the system during extreme market volatility). Parameter Adjustment: N1, Level1_threshold, ε, security threshold, etc., can all be modified through governance proposals.

[0160] The DCR intelligent adjustment algorithm provided in this application is structurally seamlessly integrated with the original "two-layer protection mechanism": Market Arbitrage (Level 1) provides immediate price correction signals and serves as the real-time trigger for DCR adjustments. Collateral Buyback (Level 2) provides feedback on asset-side security, reflected in item f4 through the Collateral Pool status and LDT ratio. The three innovative modules (Meta, AGA, and LDT) correspond to items f2 through f4 respectively, forming a self-evolving feedback path. Together with the DCR intelligent control function, these three modules constitute a "five-layer closed-loop stability system": price fluctuation → arbitrage game → collateralized repurchase → multi-anchor migration → bond buffer → dynamic collateral self-repair.

[0161] Engineering significance: Compared to the original linear algorithm, this improved model transforms DCR adjustment from a "passive response" to an "active prediction": when market volatility increases (σ_norm↑), the system automatically raises the DCR; when arbitrage profits decline or sentiment deteriorates (ΔR_aga<0), the DCR is raised in advance to prevent de-pegging; when the proportion of anchor rights shifting to crypto assets or bonds is too high, the system adaptively tightens collateral, forming a buffer layer; when the market stabilizes and liquidity recovers, the DCR gradually declines according to the cooling-off time, improving capital efficiency. This mechanism enables the system to possess intelligent dynamic stabilization capabilities of "learning-feedback-correction-recovery," constituting the core self-sensing and self-balancing module in the algorithmic stablecoin system, significantly improving anchor persistence and system resilience.

[0162] The following example illustrates the dual-token stabilization process provided in this application. The example demonstrates the complete operation of the system during a real-world fluctuation cycle, showcasing an intelligent self-evolutionary closed loop.

[0163] Phase 1: Slight derailment (TWAP = 0.97).

[0164] Oracle detected a price slightly below the anchor price (Peg). = 1.00; The system enters Level-1 state, opening the arbitrage window.

[0165] Arbitrage principle: When ST < 1 USD, users can purchase ST at the market price and redeem it at the anchor price to obtain arbitrage profits.

[0166] Calculation example: The user buys 100 ST at a cost of 100 × 0.97 = 97 USD. DCR = 0.4; collateralOut = 100 × 0.4 = 40 USD; gtValueOut = 100 × 0.6 = 60 USD; P_GT = 2 USD → gtAmount = 60 / 2 = 30 GT; Arbitrage profit = (40 + 60) - 97 = 3 USD; A decrease of 100 in supply of S drives up prices.

[0167] Phase 2: Moderate derailment (TWAP = 0.85).

[0168] If TWAP remains below 0.9, the system will trigger a Level-2 buyback.

[0169] Budget calculation: buyback_budget_ratio = 0.25; CollateralPool.reserve = 4000 USD; budgetUSD = 4000 × 0.25 = 1000 USD; Market price 0.85 → Repurchase quantity = 1000 / 0.85 = 1176 ST; After execution: S_supply_new = 10000 - 1176 = 8824 ST; C_new = 4000 - 1000 = 3000 USD; After the buyback ended, TWAP rose to 0.93, and the system entered the observation period.

[0170] Phase 3: Insufficient liquidity and the launch of LDT.

[0171] If some users still redeem 2000 ST, the collateral pool balance will only be 1500 USD; The excess amount of USD 500 cannot be redeemed immediately, and the system generates an LDT.

[0172] LDT_nominal = 500; Discount = 0.07 → Market Price = 465 USD.

[0173] Users can choose to hold LDT or sell it at a discount on the market.

[0174] The system will repurchase this bond through seigniorage revenue during a future repurchase period (e.g., two weeks later).

[0175] Phase Four: Dynamic collateral ratio and self-evolving arbitrage are adjusted in tandem.

[0176] Market volatility σ = 0.25, price deviation |TWAP-1| = 0.07, liquidity depth index depth = 0.3; DCR_target = 0.4; k_vol = 0.5, k_pr = 0.3, k_liq = 0.2; calculate: candidate = 0.4 + 0.5×0.25 + 0.3×0.07 - 0.2×0.3 = 0.4 + 0.125 +0.021 - 0.06 = 0.486.

[0177] DCR_prev = 0.45, Δ=0.05 → DCR_next = 0.45 + 0.036 = 0.486.

[0178] The system increases the collateral ratio to 48.6% to enhance the safety margin.

[0179] Meanwhile, the self-evolutionary arbitrage module detected a large historical deviation → increased the reward rate r_arb = 2.4% and extended the cooldown time by 10 minutes.

[0180] Phase 5: Adjustment of the anchor point of the meta-stabilized layer.

[0181] If the US Dollar Index (DXY) falls by 5% while the price of Bitcoin remains stable, the system will automatically adjust the anchor weight: Original: w_USD = 0.8, w_BTC = 0.2; After adjustment: w_USD = 0.6, w_BTC = 0.4; New Peg = 0.6×1.00 + 0.4×BTC_price_index; If BTC is stable against USD, the anchor price will remain stable, and the system will achieve self-stabilization.

[0182] Phase Six: Market Recovery and Bond Redemption.

[0183] As arbitrage confidence returned, TWAP rebounded to 0.99, and the system status changed from RECOVERY to NORMAL.

[0184] The agreement begins to repurchase LDT: Repurchase amount = 500 × (1 + 0.03 premium) = 515 USD; LDT holders receive an additional 3% return, and the total collateral in the system returns to a steady state.

[0185] This completes the closed loop: De-anchoring → Arbitrage → Repurchase → Collateral adjustment → Anchor rebalancing → Debt redemption → Recovery.

[0186] The improved dual-token algorithmic stablecoin system proposed in this application employs a two-layer protection mechanism (primary arbitrage adjustment + secondary collateral pool buyback), combined with dynamic collateral ratio adjustment, and has the following beneficial effects: Dynamic multi-anchor risk resistance capability: The meta-stabilization layer achieves "anchor migration" through multi-asset weighted anchoring and automatic weight adjustment, so that the system can maintain anchor stability when the dollar fluctuates, macro inflation occurs or market trust shifts.

[0187] Intelligent arbitrage self-regulation mechanism: The self-evolutionary arbitrage game module introduces machine learning-based parameter optimization, which enables the incentive and punishment mechanisms to be corrected in real time according to market behavior, avoiding excessive speculation and liquidity traps, and achieving market feedback self-balancing.

[0188] Liquidity Bond Market Buffer: The LDT mechanism tokenizes short-term liquidity risk, making system debt tradable and enabling price discovery. Users can choose their own exit path, thereby maintaining market confidence and capital flow.

[0189] Adaptive safety margin control: The dynamic collateral ratio algorithm works in conjunction with AGA, and DCR is automatically fine-tuned according to volatility and liquidity depth to achieve the optimal balance between safety and capital efficiency.

[0190] Enhanced Decentralized Resilience: All parameters and operations are executed automatically through on-chain smart contracts without human intervention, ensuring system transparency, auditability, and resistance to manipulation, and possessing true algorithmic autonomy.

[0191] Multi-layered feedback closed-loop structure: The entire system constitutes a fully closed-loop feedback system from market price → arbitrage → collateral pool → parameter learning → bond market → anchor point migration, forming a high-dimensional dynamic stable structure that can maintain anchoring under multiple shocks.

[0192] Significantly surpassing related technical solutions: Compared to related technologies, this application features "learnability," "evolutionability," and "anchor flexibility." UST's reliance on single-anchor arbitrage led to systemic collapse, while this system significantly improves resilience and recovery speed through multi-anchor migration and bond-based buffering.

[0193] Figure 8 The schematic diagram of the dual-token system stabilization processing device provided in this application includes: The dynamic anchoring module 11 is used to determine the weight change value of each candidate anchoring asset based on the stability change parameter and price fluctuation change parameter of the candidate anchoring asset; determine the second weight value of the candidate anchoring asset at the current moment based on the weight change value of the candidate anchoring asset and the first weight value of the candidate anchoring asset determined at the previous moment; and determine the target anchoring asset at the current moment based on the second weight value of each candidate anchoring asset. The dynamic arbitrage module 12 is used to determine the system's comprehensive anchor price based on the asset price and second weight value of each candidate anchor asset; determine the reverse gradient of stability deviation based on the system's comprehensive anchor price and the time-weighted average price; determine the change value of the arbitrage mechanism parameters based on the reverse gradient of stability deviation; determine the second arbitrage mechanism parameters at the current time based on the change value of the arbitrage mechanism parameters and the first arbitrage mechanism parameters determined at the previous time; and provide arbitrage incentives based on the second arbitrage mechanism parameters.

[0194] The device also includes: The Liquidity Bond Module 13 is used to determine the face value of the bonds based on the redemption request amount and the collateral pool balance when the actual available collateral pool balance is less than the amount of the redemption request initiated by the user; determine the discount rate based on the total amount of stablecoins, the bond supply, and the bond face value; determine the market price of the Liquidity Bond Mechanism based on the bond face value and the discount rate; and redeem the bonds based on the market price.

[0195] The device also includes: The dynamic collateral ratio module 14 is used to determine market risk parameters based on price volatility, price deviation, liquidity depth, and their respective third weight values; determine arbitrage behavior feedback parameters based on the current arbitrage yield and the average historical arbitrage yield; determine multi-anchor weight migration parameters based on the change in the weight value of the preset primary anchor asset; determine bond supply adjustment parameters based on the current supply of liquid bonds, total collateral pool assets, and the target market price of the liquid bond mechanism; determine the collateral ratio adjustment value based on the market risk parameters, arbitrage behavior feedback parameters, multi-anchor weight migration parameters, and bond supply adjustment parameters; and determine the predicted collateral ratio based on the current collateral ratio and the collateral ratio adjustment value.

[0196] The dynamic anchor module 11 is also used to determine the weight change value of each candidate anchor asset based on the stability change parameter and price fluctuation change parameter of the candidate anchor asset if the time-weighted average price is less than the preset first price threshold for a first number of consecutive times within the historical sampling time window.

[0197] The liquidity bond module 13 is also used to determine the face value of the bond based on the redemption request amount and the collateral pool balance if, within the historical sampling time window, the time-weighted average price is less than a preset second price threshold for a second consecutive number of times; or the collateral pool balance is less than a preset safety threshold.

[0198] The device also includes: The casting redemption module 15 is used to switch back to the normal state when the system is initialized; or when the time-weighted average price recovers to the preset range and liquidity recovers. The minting process under normal conditions includes: a user initiating a minting request, which includes the target amount of stablecoin to be minted, an array of collateral token types, and the quantity of governance tokens; if the time-weighted average price is normal, the collateralization ratio is obtained, and the asset requirement is calculated based on the collateralization ratio; the asset requirement includes the value of the required collateral and the value of the governance tokens to be burned; the collateral tokens are transferred to the collateral pool, the governance tokens are burned to the treasury, and stablecoins are minted and distributed to the user's address. The redemption process under normal conditions includes: the user initiates a redemption request, which includes the amount of stablecoins to be destroyed, the minimum amount of collateral output, and the minimum amount of governance tokens output; the collateralization ratio and the total value of the collateral pool are obtained, and the assets to be returned are calculated based on the collateralization ratio; the assets to be returned include the value of the collateral to be returned and the value of the governance tokens to be returned; if the collateral pool funds meet the redemption requirements, an equivalent amount of collateral is transferred from the collateral pool to the user, and an equivalent amount of governance tokens is transferred from the treasury to the user; otherwise, the process of redeeming bonds is carried out.

[0199] The dynamic anchoring module 11 is specifically used to determine the second weight value of the candidate anchoring asset i at the current time according to the formula wi(t+1) = wi(t) + α × (ΔSi - β × ΔVi); where wi(t+1) is the second weight value of the candidate anchoring asset i at the current time, wi(t) is the first weight value of the candidate anchoring asset i determined at the previous time, Δsi is the stability change parameter, Δvi is the price fluctuation change parameter, and α and β are learning rate coefficients.

[0200] Dynamic arbitrage module 12 is specifically used to calculate based on the formula θ(t+1) = θ(t) + η× (- |TWAP- Peg) | ) / θ determines the parameters of the second arbitrage mechanism at the current time; where θ(t+1) is the parameter of the second arbitrage mechanism at the current time, θ(t) is the parameter of the first arbitrage mechanism determined at the previous time, TWAP is the time-weighted average price, and Peg is the price at the current time. η is the overall anchor price of the system, and η is the learning rate.

[0201] The Liquidity Bonds module 13 is specifically used to input the total amount of stablecoins, bond supply, and bond face value into the formula discount = base_rate + γ × (LDT_nominal / total_supply_ST) to determine the discount rate; where discount is the discount rate, base_rate is the bond supply, LDT_nominal is the bond face value, total_supply_ST is the total amount of stablecoins, and γ is the preset risk coefficient.

[0202] Dynamic collateral ratio module 14, specifically used to calculate the collateral ratio based on the formula clamp([k_vol)). σ_norm + k_pr price_norm - k_liq depth_norm]+ [β1 ΔR_aga]+ [β2 ΔW_meta]+ [β3 (LDT_supply_ratio - LDT_target)] , -Δ, +Δ ), determine the collateral ratio adjustment value; where, clamp is the constraint function, σ_norm is the normalized price volatility, price_norm is the normalized price deviation, depth_norm is the normalized liquidity depth, k_vol , k_pr , k_liq are the third weight values ​​corresponding to the normalized price volatility, normalized price deviation, and normalized liquidity depth, respectively, ΔR_aga is the difference between the current arbitrage yield and the average historical arbitrage yield, β1 ΔR_aga is the arbitrage behavior feedback parameter, β2 ΔW_meta is the multi-anchor weight migration parameter, LDT_supply_ratio is the ratio of current liquid bond supply to total collateral pool assets, LDT_target is the target market price of the liquid bond mechanism, and β3 (LDT_supply_ratio - LDT_target) is the bond supply adjustment parameter, and β1, β2 and β3 are weight values.

[0203] This application also provides an electronic device, such as Figure 9 As shown, it includes: processor 21, communication interface 22, memory 23 and communication bus 24, wherein processor 21, communication interface 22 and memory 23 communicate with each other through communication bus 24; The memory 23 stores a computer program, which, when executed by the processor 21, causes the processor 21 to perform any of the above method steps.

[0204] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0205] Communication interface 22 is used for communication between the above-mentioned electronic device and other devices.

[0206] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0207] The processors mentioned above can be general-purpose processors, including central processing units, network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits, field-programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0208] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform any of the above method steps.

[0209] This application provides a computer program product, which includes an executable program that implements a method when executed by a processor.

[0210] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0211] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for stable processing of a dual token system, characterized by, The method comprises: For each candidate anchor asset, a weight change value of the candidate anchor asset is determined according to a stability change parameter and a price fluctuation change parameter of the candidate anchor asset; a second weight value of the candidate anchor asset at the current time is determined according to the weight change value of the candidate anchor asset and a first weight value of the candidate anchor asset determined at the last time; and a target anchor asset at the current time is determined according to the second weight value of each of the candidate anchor assets; A system comprehensive anchor price is determined according to the asset price and the second weight value of each of the candidate anchor assets; a reverse gradient of a stability deviation is determined according to the system comprehensive anchor price and a time-weighted average price; a change value of an arbitrage mechanism parameter is determined according to the reverse gradient of the stability deviation; a second arbitrage mechanism parameter at the current time is determined according to the change value of the arbitrage mechanism parameter and a first arbitrage mechanism parameter determined at the last time; and arbitrage incentives are performed according to the second arbitrage mechanism parameter.

2. The method of claim 1, wherein, The method further comprises: If an actual available balance of a mortgage pool in the current mortgage pool is less than a current redemption request amount initiated by a user, a bond face value is determined according to the redemption request amount and the mortgage pool balance; A discount rate is determined according to the total number of stablecoins, the bond supply amount and the bond face value; A market price of a liquidity bond mechanism is determined according to the bond face value and the discount rate, and the bond is redeemed according to the market price.

3. The method of claim 2, wherein, The method further comprises: Market risk parameters are determined according to a price fluctuation rate, a price deviation, a liquidity depth and a third weight value corresponding to each; An arbitrage behavior feedback parameter is determined according to a current arbitrage yield and an average historical arbitrage yield; A multi-anchor weight migration parameter is determined according to a preset weight value change amount of a main anchor asset; A bond supply adjustment parameter is determined according to a current liquidity bond supply amount, total mortgage pool assets and a target market price of the liquidity bond mechanism; A mortgage rate adjustment value is determined according to the market risk parameter, the arbitrage behavior feedback parameter, the multi-anchor weight migration parameter and the bond supply adjustment parameter; A predicted mortgage rate is determined according to a current mortgage rate and the mortgage rate adjustment value.

4. The method of claim 1, wherein, Before the process of determining, for each candidate anchor asset, a weight change value of the candidate anchor asset according to a stability change parameter and a price fluctuation change parameter of the candidate anchor asset, the method further comprises: If the time-weighted average price is less than a preset first price threshold for a first number of consecutive times within a historical sampling time window, the process of determining, for each candidate anchor asset, a weight change value of the candidate anchor asset according to a stability change parameter and a price fluctuation change parameter of the candidate anchor asset is performed.

5. The method of claim 2, wherein, Before determining, if an actual available balance of a mortgage pool in the current mortgage pool is less than a current redemption request amount initiated by a user, a bond face value according to the redemption request amount and the mortgage pool balance, the method further comprises: In a historical sampling time window, if the time-weighted average price is less than a preset second price threshold for a second number of consecutive times, or the balance of the mortgage pool is less than a preset safety threshold, when the actual available balance of the mortgage pool in the current mortgage pool is less than the current redemption request amount initiated by the user, the process of determining the bond face value according to the redemption request amount and the mortgage pool balance is performed.

6. The method of claim 1, wherein, The method further comprises: In the normal state of system initialization; or the time-weighted average price returns to the preset range and the liquidity recovers, the normal state is switched back; The casting process in the normal state comprises: a user initiates a casting request, the casting request carrying a stable currency target amount to be cast, an array of mortgage token types, and a number of governance tokens; if the time-weighted average price is normal, a mortgage rate is obtained, and an asset demand is calculated according to the mortgage rate; wherein the asset demand comprises a required mortgage value and a required governance token value to be destroyed; the mortgage token is transferred into the mortgage pool, the governance token is destroyed into the fund pool, the stable currency is cast and issued to the user address; The redemption process in the normal state comprises: a user initiates a redemption request, the redemption request carrying a number of stable currencies to be destroyed, a minimum output amount of mortgage, and a minimum output amount of governance token; a mortgage rate and a total value of the mortgage pool are obtained, and a returned asset is calculated according to the mortgage rate; wherein the returned asset comprises a returned mortgage value and a returned governance token value; if the mortgage pool fund meets the redemption requirement, the equivalent mortgage is transferred from the mortgage pool to the user, and the equivalent governance token is transferred from the fund pool to the user; otherwise, the process of redeeming the bond is performed.

7. The method of claim 1, wherein, The determination of the second weight value of the candidate anchor asset at the current time comprises: According to the formula wi(t+1) = wi(t) + α × (ΔSi - β × ΔVi), the second weight value of the candidate anchor asset i at the current time is determined; Wherein, wi(t+1) is the second weight value of the candidate anchor asset i at the current time, wi(t) is the first weight value of the candidate anchor asset i determined at the last time, Δsi is a stability change parameter, Δvi is a price fluctuation change parameter, and α and β are learning rate coefficients.

8. The method of claim 1, wherein, The determination of the second arbitrage mechanism parameter at the current time comprises: According to the formula θ(t+1) = θ(t) + η × ( - |TWAP - Peg | ) / θ, the second arbitrage mechanism parameter at the current moment is determined. In the formula, θ(t+1) is the second arbitrage mechanism parameter at the current time, θ(t) is the first arbitrage mechanism parameter determined at the last time, TWAP is the time weighted average price, Peg is the system comprehensive anchor price, and η is a learning rate.

9. The method of claim 2, wherein, The determination of the discount rate according to the total number of stable currencies, the bond supply, and the bond face value comprises: The total number of stable currencies, the bond supply, and the bond face value are brought into the formula discount = base_rate +γ× (LDT_nominal / total_supply_ST) to determine the discount rate; Wherein, discount is the discount rate, base_rate is the bond supply, LDT_nominal is the bond face value, total_supply_ST is the total number of stable currencies, and γ is a preset risk coefficient.

10. The method of claim 3, wherein, The determination of the mortgage rate adjustment value according to the market risk parameter, the arbitrage behavior feedback parameter, the multi-anchor weight migration parameter, and the bond supply adjustment parameter comprises: According to the formula clamp([k_vol σ_norm + k_pr price_norm - k_liq depth_norm]+[β1 ΔR_aga]+ [β2 ΔW_meta]+ [β3 (LDT_supply_ratio - LDT_target)], -Δ, +Δ ), determine the mortgage rate adjustment value; In the formula, clamp is a limiting function, σ_norm is the normalized price volatility, price_norm is the normalized price deviation, depth_norm is the normalized liquidity depth, k_vol, k_pr, and k_liq are respectively the third weight values corresponding to the normalized price volatility, the normalized price deviation, and the normalized liquidity depth, ΔR_aga is the difference between the current arbitrage yield and the average historical arbitrage yield, β1 ΔR_aga is a arbitrage behavior feedback parameter, β2 ΔW_meta is a multi-anchor weight migration parameter, LDT_supply_ratio is the ratio of the current liquidity bond supply to the total collateral pool assets, LDT_target is the target market price of the liquidity bond mechanism, β3 (LDT_supply_ratio- LDT_target) is a bond supply adjustment parameter, and β1, β2, and β3 are weight values.

Images