Skip to main content
本頁內容由 AI 自動翻譯,所有內容以英文版本為準。查看英文版 →
LaunchLab 公開了一套精簡的指令集:六個面向使用者的呼叫加上少數管理員原語。SDK 包裝了所有這些;本頁面記錄了原始介面,供聚合器、監控工具和需要 CPI 的程式使用。2026-09 程式升級在 Anchor 1.0.2 / Solana 3.1.10 上重建了 LaunchLab,並清除了三個轉換機制:已棄用的 Initialize 現在總是失敗,MigrateToAmm 失去了它的三個參數和每個 OpenBook 帳戶,而 get_upgrade_timestamp 閘道(使多個檢查以時鐘為條件)已消失。它還新增了一個管理員指令 CollectExcessLamports。參見 2026-09-09 變更日誌條目。

指令清單

「ExactIn/ExactOut」分割鏡像 CPMM 的 SwapBaseInput / SwapBaseOutput — 在鏈上它們是具有略微不同舍入的單獨指令判別器。 畢業路徑選擇。 每個新的 InitializeV2 和 InitializeWithToken2022 呼叫都必須設定 migrate_type = 1(CPSWAP)。任何嘗試初始化新的 AMM v4 綁定池都會返回 MigrateTypeNotMatch。amm_creator_fee_on 僅選擇結果 CPMM 建立者費用是否適用於報價代幣或兩個代幣;它不選擇目標程式。舊版 Initialize 根本無法再建立啟動(見下文)。 MigrateToAmm 對於在此限制之前使用 migrate_type = 0 初始化的現有 PoolState 仍可呼叫。該版本不會重寫現有池狀態或移除舊版指令。 報價端代幣程式。 報價鑄幣可由 SPL Token 程式或 Token-2022 擁有。每個接觸它的指令 — CreateConfig、InitializeV2、InitializeWithToken2022、所有四個交易指令、CollectFee、CollectMigrateFee、ClaimCreatorFee、ClaimPlatformFee 和 ClaimPlatformFeeFromVault — 在其報價程式帳戶槽中取得擁有程式。帳戶位置未改變;只有接受的值改變了。傳遞實際擁有 GlobalConfig.quote_mint 的程式,你可以從現有啟動的 PoolState.token_program_flag bit1 讀取(見 accounts)或從鑄幣帳戶的擁有者讀取。 已棄用的 Initialize 在這裡無關緊要:其報價程式帳戶仍然被類型化為 SPL Token,由於 2026-09 升級,該指令在讀取任何帳戶之前失敗。透過 InitializeV2 或 InitializeWithToken2022 啟動。 MigrateToCpswap 是另一個例外,方向相反 — 它無條件地取得兩個程式,而不是每個鑄幣一個。見下面的 遷移帳戶。

Initialize

自 2026-09 升級起實際上已移除 — 此指令總是失敗。 initialize 的處理程式現在只是 Not supported. Please use initialize_v2 instruction 和 NotApproved(6000)的日誌。它純粹保留以便其判別器保持佔用且 IDL 保持穩定形狀。(Accounts 結構未改變,所以 Anchor 的生成驗證仍然首先執行;無論如何交易都會還原。)以前它以時鐘為條件:它在 get_upgrade_timestamp 切換後三天內有效,之後失敗。該時間戳幫助程式已消失,所以失敗現在是無條件的。透過它建立的現有啟動不受影響 — 它們透過 MigrateToAmm 或 MigrateToCpswap 正常交易和畢業,取決於它們儲存的 migrate_type。下面的參數和帳戶列表是 InitializeV2 的。已棄用的 Initialize 以相同順序取得相同的 18 個帳戶, 而且只有前三個參數 — 它沒有 amm_fee_on — 並且它的 quote_token_program 插槽的型別是 SPL Token,而不是 Interface<TokenInterface>。
建立新發行。相對於已棄用的 Initialize,InitializeV2 只多加了 amm_fee_on 參數;帳戶的數量和順序完全相同,唯一的帳戶層級差異是 quote_token_program 的型別為 Interface<TokenInterface>,因此可以接受 Token-2022 報價鑄幣。 參數 四個位置參數,而不是一個結構。(InitializeWithToken2022 會附加第五個 transfer_fee_extension_param: Option<TransferFeeExtensionParams>;已棄用的 Initialize 則沒有 amm_fee_on。)
該變體必須與 global_config.curve_type 相符,否則指令會以 InputNotMatchCurveConfig(6003)還原。沒有 open_time、沒有 quote_mint 參數(它來自 global_config)、沒有 fees 結構,也沒有 post_graduation_lp_policy — LP 處置是在 PlatformConfig 上設定的,而不是每次發行各自設定。 帳戶 — 總共 18 個(16 個宣告的,加上 #[event_cpi] 附加的兩個) 前置條件
  • quote_mint ∈ launch_config.allowed_quote_mints。
  • base_supply_graduation ≤ base_supply_max。
  • 費用參數通過 launch_config.max_*_fee_rate 檢查。
  • open_time ≥ now − slop(SDK 強制 ≥ now;程式容許輕微回溯)。
  • curve_type 被識別。
後置條件
  • base_mint 有 supply = curve_param.supply,全部在 base_vault 中。
  • 鑄幣權限在供應量鑄造完成後,就在這同一條指令中被撤銷(set_authority(MintTokens, None)) — 而不是在畢業時。因此基礎鑄幣永久固定供應量,之後沒有任何指令能再鑄造。
  • PoolState 初始化為 status = Fund(0)、real_a = 0、real_b = 0。
  • total_fund_raising_b 直接來自 curve_param.total_quote_fund_raising。
  • 對於帶有 TransferFeeConfig 的 InitializeWithToken2022:transfer_fee_config_authority = launch_authority,且 withdraw_withheld_authority = PlatformConfig.transfer_fee_extension_auth(當該欄位被設定時),否則為 launch_authority。提取端在鑄幣建立時被寫入,正是為了讓平台可以在畢業前掃除扣留的費用。見 platform-config。
常見錯誤 — NotApproved(6000,對已棄用的 Initialize 為無條件)、InvalidInput(6002,違反了來自 GlobalConfig 的供應量/費率/募資下限)、InputNotMatchCurveConfig(6003,curve_param 變體與 global_config.curve_type 不符)、MigrateTypeNotMatch(6007,migrate_type != 1)、MathOverflow(6008)、VestingRatioTooHigh(6010)、NoSupportExtension(6017)、NotEnoughRemainingAccounts(6018)、InvalidPlatformAllowConfig(6022)、CurveParamNotMatchPlatformRule(6025)。失敗的 Anchor address = / constraint = 檢查會顯示為 2xxx 代碼,而不是上述任何一個 — InvalidQuoteMint、FeeRateTooHigh 和 InvalidCurveParams 都不存在於該程式的錯誤列舉中。

Buy(規範變體:BuyExactIn)

使用者提供固定的輸入金額;曲線計算輸出。 參數
帳戶 剩餘帳戶 — 費用管線,按這個確切順序讀取:
  1. share_fee_receiver — 僅在 share_fee_rate > 0 時。
  2. system_program — 總是需要;檢查 == System::id(),否則 InvalidInput。
  3. platform_fee_vault — PDA [platform_config, quote_token_mint];首次使用時建立。
  4. creator_fee_vault — PDA [creator, quote_token_mint];首次使用時建立。
數量不足會返回 NotEnoughRemainingAccounts(6018)。沒有 associated_token_program 插槽,而 system_program 是剩餘帳戶而不是宣告的帳戶。 前置條件
  • launch_state.status == Active。
  • now ≥ open_time。
  • user_quote_ata.balance ≥ quote_in。
  • quote_in > 0。
效果
  1. 將 quote_in 分割為 quote_in_after_fee 和費用部分。
  2. 牛頓求解曲線以獲得給定後費用報價的 base_out。
  3. require(base_out ≥ minimum_base_out) 否則還原 ExceededSlippage。
  4. 移動 quote_in 使用者 → 金庫。移動 base_out 金庫 → 使用者。
  5. 更新 base_sold += base_out、quote_reserve_real += quote_in_after_fee × (lp_share / total_share)。
  6. 更新費用計數器(protocol_fees_quote、creator_fees_quote)。
  7. state_data.num_buys += 1。
  8. 如果更新後 quote_reserve_real ≥ quote_reserve_target,SDK 通常在同一交易中鏈接 Graduate ix。程式不在 Buy 內自動畢業 — 需要後續的 Graduate。

BuyExactOut

使用者指定精確的 base_out;程式計算 quote_in。 參數
與 BuyExactIn 相同的帳戶,也是相同的剩餘帳戶契約。使用閉式二次積分(或 CPMM 反函數,對於 curve_type 1),而不是牛頓迭代。

Sell / SellExactIn / SellExactOut

Buy 的鏡像。使用者將 base_in 返回曲線並接收 quote_out。費用從 quote_out 中扣除,所以使用者收到的少於原始整合收益。 前置條件 —
  • user_base_ata.balance ≥ base_in。
  • 賣出不能將 base_sold 推低於 0(給定會計一致,與上述冗餘)。
  • 啟動是 Active。
效果 — 對稱於 Buy。base_sold 減少,quote_reserve_real 減少。費用仍然累積。

報價端轉帳費用

當報價鑄幣帶有 TransferFeeConfig 時,金庫移動的金額和支付者被扣除或貸記的金額不同,滑點界限針對支付者端檢查。在沒有擴展的報價鑄幣上,下面的每個情況都與普通舊版鑄幣相同。 報價的兩個後果:
  • 計算為鑄幣無費用的界限被拒絕。傳遞無費用成本作為 maximum_amount_in,或無費用收益作為 minimum_amount_out,還原為 ExceededSlippage。
  • real_quote 僅按到達金庫的內容推進。5% 報價鑄幣上的 BuyExactIn 為 amount_in 移動 real_quote 為 amount_in × 0.95。
100% 費用報價鑄幣(10000 基點)無法反轉,在精確輸出路徑上還原為 CalculateOverflow。 兩個交易端鑄幣也被限制為在其匹配槽中傳遞的程式,所以不匹配的 base_token_program 現在失敗而不是被忽略。見 algorithms/token-2022-transfer-fees 以瞭解基礎費用數學。

交易剩餘帳戶

所有四個交易指令透過 remaining_accounts 按此順序取得其費用管道:
在 2026-09 中改變:最後三個現在是無條件的,system_program 被驗證。 在此版本之前,程式僅在 unix_timestamp >= get_upgrade_timestamp() 時讀取它們,並在該時刻之前完全跳過平台/建立者費用分割。時間戳已過去,所以主網上的行為實際上未改變 — 但分支已從程式碼中移除,仍然省略三個帳戶的建立者現在總是以 NotEnoughRemainingAccounts(6018)失敗,而不是僅在切換後。system_program 槽另外針對 System::id() 檢查,如果它持有其他內容則返回 InvalidInput(6002),而以前任何帳戶都在該位置被接受。

MigrateToAmm / MigrateToCpswap

一旦曲線達到 total_quote_fund_raising,將啟動畢業為可交易的池。新啟動僅限 CPMM。MigrateToAmm 為儲存的 migrate_type 為 0 的現有池保留。 誰簽署
  • MigrateToAmm — 綁定 GlobalConfig 上記錄的 migrate_to_amm_wallet。
  • MigrateToCpswap — 綁定 GlobalConfig 上記錄的 migrate_to_cpswap_wallet。
這些錢包通常由 Raydium 運營的畢業曲柄持有;實際上畢業在超過閾值後幾秒內進行,無論誰觸發最後的買入。 參數 都不帶任何。
破壞性變更(僅遷移錢包,2026-09)。 MigrateToAmm 放棄了所有三個參數 — base_lot_size、quote_lot_size、market_vault_signer_nonce — 和九個帳戶。其指令資料現在是裸判別器,所以舊建立者既發送 17 個意外的參數位元組,又提供不再對齊的帳戶列表。這遵循 AMM v4 自己的 OpenBook 移除:AMM v4 的 Initialize2 不再取得 market_program 或 amm_open_orders,所以 LaunchLab 沒有什麼可轉發的。程式也停止了 CPI-ing initialize_openbook_market,這是三個參數配置的內容。移除的帳戶:openbook_program、request_queue、event_queue、bids、asks、market_vault_signer、market_base_vault、market_quote_vault 和 amm_open_orders。market 帳戶保留在其位置 — AMM v4 仍將其記錄為參考欄位 — 但現在被宣告為裸 #[account(mut)]:無擁有者、地址或種子約束。它完全未驗證,它直接轉發到 AMM v4 的 Initialize2 CPI,程式不再初始化它。想要市場帳戶是真實初始化市場的呼叫者必須事先自己建立它。剩餘的 23 帳戶列表按順序為:payer、base_mint、quote_mint、market、amm_program、amm_pool、amm_authority、amm_lp_mint、amm_base_vault、amm_quote_vault、amm_target_orders、amm_config、amm_create_fee_destination、authority、pool_state、global_config、base_vault、quote_vault、pool_lp_token、spl_token_program、associated_token_program、system_program、rent_program。MigrateToCpswap 不受影響 — 它從未有參數。
效果(兩者共同)
  1. 驗證 pool_state.status == Migrate(即 quote_reserve_target 已達到)。否則還原為 PoolMigrated(狀態已是 Migrated)或 PoolFunding(仍在籌資)。
  2. 驗證 pool_state.migrate_type 匹配指令(AMM 為 0,CPMM 為 1)。否則還原為 MigrateTypeNotMatch。
  3. 計算畢業後的準備金:
    • base_amount_out = base_vault.amount − vesting_schedule.total_locked_amount
    • quote_amount_out = quote_vault.amount − quote_protocol_fee − migrate_fee − platform_fee
  4. CPI 進入目標程式(AMM v4 Initialize2 或 CPMM InitializeWithPermission)使用這些準備金建立畢業後的池。
  5. 對於在 2026-08-17 升級後執行的 CPMM 遷移,將 platform_scale + creator_scale 合併為一個平台擁有的鎖定 LP 份額,並最多向 platform_nft_wallet 鑄造一個費用金鑰 NFT。燒毀 burn_scale 餘數。在升級之前,creator_scale 被單獨鎖定,其費用金鑰進入代幣建立者。已完成的歷史遷移不被修改。對於舊版 AMM v4 畢業,LP 處置遵循該指令的現有流程。
  6. (無鑄幣授權步驟。base_mint.mint_authority 已在啟動建立時設定為 None — 見下面的註釋。)
  7. 翻轉 pool_state.status = Migrated,設定 vesting_schedule.start_time = block_time + cliff_period。
Token-2022 轉帳費用授權交接 — 當基礎鑄幣是帶有 TransferFeeConfig 的 Token-2022 鑄幣且 PlatformConfig.transfer_fee_extension_auth 非預設時,遷移也將該擴展的授權重新分配給平台金鑰:
  • transfer_fee_config_authority 總是被重新分配。啟動 authority PDA 在整個畢業前階段持有它,所以總有東西要移動。
  • WithheldWithdraw 僅在 authority PDA 仍持有它時被重新分配。從 2026-08-27 起建立的啟動已經在鑄幣建立時在該授權上帶有 transfer_fee_extension_auth,所以該步驟被跳過。守衛是什麼讓遷移不在這些鑄幣上還原 — PDA 無法簽署它不再持有的授權。
如果 transfer_fee_extension_auth 在遷移時是 Pubkey::default(),兩個授權都不移動,兩個都永久保留在 authority PDA。見 platform-config。
基礎鑄幣的供應從建立時固定,而不是從畢業時。 InitializeV2 和 InitializeWithToken2022 將整個供應鑄造到基礎金庫中,然後在同一指令中立即撤銷 MintTokens,所以 base_mint.mint_authority 在啟動的整個生命週期中是 None。遷移不接觸它。(本頁的早期修訂將撤銷放在畢業時;那是錯誤的。)遷移唯一可以移動的授權是下面描述的 Token-2022 轉帳費用授權。
後置條件 — BuyExactIn、BuyExactOut、SellExactIn、SellExactOut 將從此點起以 PoolMigrated 拒絕。結果 AMM 池是規範的,交易像任何其他 AMM v4 / CPMM 池。 常見錯誤 — PoolFunding、PoolMigrated、MigrateTypeNotMatch、InvalidCpSwapConfig、MathOverflow。

CPMM 遷移剩餘帳戶

建立 MigrateToCpswap 的客戶端必須使用這些固定的 remaining_accounts 索引: 指令至少需要十個剩餘帳戶。支援鑄幣帳戶是唯讀 CPI 輸入。即使鑄幣沒有初始化的支援記錄,也要衍生兩個地址。仍然附加建立者鎖定帳戶或省略索引 8–9 的舊建立者必須更新。
在 2026-09 中改變。 兩個清理,都不改變正確的建立者:
  • 許可 CPMM 路徑現在是唯一的路徑。 MigrateToCpswap 曾經根據 unix_timestamp >= get_upgrade_timestamp() 在 InitializeCpSwap 和 InitializeCpSwapWithPermission 之間選擇。時間戳幫助程式和舊版 CPI 都已消失,所以許可路徑 — 因此十帳戶最小值 — 無條件適用。
  • 三個地址約束從帳戶結構移入指令主體。 platform_config、base_vault 和 quote_vault 仍然需要匹配儲存在 PoolState 上的值,但不匹配現在由 require_keys_eq! 而不是 Anchor 的 address = 約束引發。檢查是等效的;只有錯誤表面不同 — 你得到 Anchor 的通用 RequireKeysEqViolated(2502)而不是 ConstraintAddress(2012),它被報告而沒有帳戶名稱。更新任何匹配這三個帳戶的 2012 的錯誤處理。

CPMM 遷移代幣程式

MigrateToCpswap 無條件地取得兩個代幣程式,並自己計算出哪個擁有每個鑄幣。其兩個代幣程式帳戶被相應地重新命名: 它們替換了前者的 base_token_program(無論哪個程式擁有基礎鑄幣)和 quote_token_program(總是舊版)。位置未改變,所以這是值變更而不是佈局變更 — 但兩個值幾乎相反,保持傳遞舊對的建立者將在任一鑄幣是 Token-2022 鑄幣時立即在需要舊版程式的地方提供 Token-2022。 舊版程式是必需的,即使兩個鑄幣都不使用它,因為 CPMM LP 鑄幣和鎖定流動性費用金鑰 NFT 總是在它上面。

平台 GlobalConfig 允許清單

PlatformConfig.restrict_global_config 控制檢查:
  • 0:平台接受任何其他有效的 GlobalConfig;不需要允許帳戶。
  • 1:Initialize、InitializeV2 和 InitializeWithToken2022 必須在 remaining_accounts 中的任何地方包含匹配的 PlatformAllowConfig。
平台管理員使用 CreatePlatformAllowConfig 和 ClosePlatformAllowConfig 建立或關閉 PDA。其種子是 [b"platform_allow_config", platform_config, global_config]。前者管理員管理的 PlatformGlobalAccess 指令和 PDA 已停用。

平台啟動參數規則

四個指令管理一個 PlatformCurveRule 帳戶。所有四個都由 PlatformConfig.curve_rule_manager 或平台管理員簽署 — 程式透過從簽署者重新衍生 PlatformConfig PDA 接受管理員,所以沒有單獨的帳戶證明它。既不是簽署者的返回 InvalidCurveRuleAuthority。 platform_curve_rule 是 [b"platform_curve_rule", platform_config, global_config] 的 PDA。
  • Create 分配不持有任何群組的帳戶。該狀態不限制任何內容。
  • Update 使用該 group_id 更新插入群組,如果存在則完全替換它。它調整帳戶大小以適應,所以簽署者補充它增長的租金並收回它縮小的租金。超過第十個的新群組返回 CurveRuleGroupsExceeded;超過 25 個約束、未知欄位或運算子,或同一群組中相同的 (field, op) 對兩次返回 InvalidCurveRuleConstraint;非常數乘積配置上的四個 TotalSellA 衍生欄位返回 CurveRuleFieldNotSupportedByCurve。
  • Remove 按 id 放棄一個群組,縮小帳戶並退款差異。未知 id 返回 CurveRuleGroupNotExist。
  • Close 將整個租金返回給簽署者。配置隨後再次不受限制,即使 restrict_curve_param 保持 1。
四個都不改變規則是否被強制執行。那是 UpdatePlatformConfig::RestrictCurveParam(0 | 1),只有平台管理員可以呼叫。 在啟動路徑上。 當 restrict_curve_param 是 1 時,InitializeV2 和 InitializeWithToken2022 需要 remaining_accounts 中的規則 PDA — 包括當它不存在時,以便省略它無法跳過檢查。缺少帳戶是 NotEnoughRemainingAccounts;不滿足任何群組的啟動是 CurveParamNotMatchPlatformRule。檢查在 GlobalConfig 自己的限制之前執行,只能縮小它們。模型和劇本:products/launchlab/curve-rules。兩個錯誤都可以在客戶端避免 — SDK 將此檢查鏡像為純函數,見 發送前檢查。

CollectFee

協議在單個啟動上累積交易費用的管理員掃除。 參數 — 無。 帳戶
這裡 quote_mint 排在 recipient_token_account 之前 — 與 ClaimCreatorFee、 ClaimPlatformFee 和 ClaimPlatformFeeFromVault 相反,那三者都把收件人放在前面。這兩個 插槽有不同的 Anchor 型別(Mint 與 TokenAccount),因此把它們調換會在執行時反序列化失敗, 讀起來就像是傳錯帳戶的 bug。CollectMigrateFee 的順序與 CollectFee 相同。
效果 — 從 quote_vault 轉帳 pool_state.quote_protocol_fee 到 recipient_token_account,然後將計數器歸零。可在第一次買入後的任何時間呼叫。

CollectMigrateFee

遷移費用的管理員掃除,在畢業時累積。與 CollectFee 相同的帳戶形狀,以 migrate_fee_owner 作為簽署者(而不是 protocol_fee_owner)和 pool_state.migrate_fee 作為排空的計數器。

ClaimCreatorFee

每個建立者掃除,跨越建立者擁有的每個使用相同報價鑄幣的啟動累積的建立者費用。排空每個建立者費用金庫,而不是每個池的。 參數 — 無。 帳戶 效果 — 轉帳 creator_fee_vault 的全部餘額到 recipient_token_account。如果金庫為空,還原為大於零檢查。

ClaimPlatformFee

每個平台掃除,直接排空啟動的報價金庫。當平台想要為一個特定啟動聲稱其份額而不透過聚合平台金庫時使用。 參數 — 無。 帳戶 效果 — 從 quote_vault 轉帳 pool_state.platform_fee 到 recipient_token_account,將計數器歸零。

ClaimPlatformFeeFromVault

每個平台聚合掃除。排空平台的每個報價鑄幣費用金庫,該金庫從透過平台路由的每個啟動累積費用。 參數 — 無。 帳戶 效果 — 轉帳 platform_fee_vault 的全部餘額到 recipient_token_account。如果金庫為空,還原。

CollectExcessLamports

管理員掃除 LaunchLab 控制的帳戶上超過租金豁免最低額的 lamports。在 2026-09 升級中新增,以便協議可以回收 SIMD-0437 租金減少 在每個步驟之前建立的帳戶上留下的過度資金。 只有超額移動。代幣餘額、帳戶資料、擁有者、曲線狀態和歸屬保持不變,指令對已在其最小值的帳戶是無操作 — 所以在每個推出步驟後重新執行是安全的。 參數 — 無。 帳戶 選擇 authority 帳戶未檢查地傳遞並由程式解析,程式重新衍生 LaunchLab 的所有三個授權 PDA 並匹配: 不匹配三個中任何一個的金鑰使整個指令以 InvalidOwner(6001)失敗。
按授權對源帳戶分組。 一個呼叫帶有一個 authority,代幣程式需要帳戶的實際擁有者簽署。由不同於你傳遞的 authority 的三個 PDA 之一擁有的代幣帳戶使 CPI 失敗並帶走整個交易。在單獨的交易中掃除池金庫、平台費用金庫和建立者費用金庫。程式擁有的 PDA 是例外 — 它們被直接扣除,所以它們可以與任何授權一起進行。
每個源帳戶的處理方式 基礎鑄幣無法被掃除。 InitializeV2 和 InitializeWithToken2022 在鑄造供應的同一指令中撤銷基礎鑄幣上的 MintTokens,所以沒有金鑰可以為它簽署 WithdrawExcessLamports — 鑄幣的租金永久保留在原地。 常見錯誤 — InvalidOwner(6001,錯誤簽署者或不是三個 PDA 之一的 authority)、LamportsCalculateError(6031,wSOL 往返沒有淨為零)和來自程式擁有路徑的 InsufficientFunds,當帳戶持有少於其自己的租金最低額時。 無 SDK 建立者。 @raydium-io/raydium-sdk-v2 不提供此指令的建立者,raydium-sdk-V2-demo 儲存庫也不提供 — 它是管理員路徑。手動編碼,就像 solana-fundamentals/rent-and-reclaimable-rent 中的錢包端掃除對代幣程式指令所做的那樣。

歸屬和平台設定指令

這些記錄在專用頁面上,因為每個都有自己的狀態模型:

狀態變更矩陣

下一步去哪裡

來源: