Vesting Schedule

如果我是一個 Agent Token 項目的一般投資人（不是團隊或早期投資人），Vesting Schedule 對我來說有什麼實際意義，需要特別關注嗎？

即使你手上的代幣沒有 Vesting 限制(一般在公開市場買到的代幣通常是即時流通、沒有鎖定的)，其他人手上有 Vesting 限制的代幣,依然會直接影響你持有的代幣未來的價格走勢,值得特別關注,原因有兩層。

第一層:解鎖時間點是可預測的供給衝擊。因為 Vesting Schedule 通常寫在公開的智能合約裡,任何人都可以查到「團隊和早期投資人的代幣,會在哪些日期解鎖多少數量」,這代表市場上所有參與者,理論上都能提前知道未來會有一波供給增加。這種可預測性,會讓部分交易者在解鎖日期前提前賣出(預期解鎖後價格會因為供給增加而下跌,提前跑掉),這種「搶跑」行為本身,反而可能導致價格在解鎖日期前就開始下跌,不完全是解鎖當下才發生的事,而是解鎖前的一段時間就會反映在價格上。

第二層:解鎖規模相對於當前流通量的比例,決定了衝擊有多大。一次解鎖釋放的代幣數量,如果相對於當前市場上已經流通的數量佔比很小(例如只增加 1-2%),市場通常能輕鬆消化,價格影響有限；但如果某次解鎖釋放的數量,相對於當前流通量佔比很大(例如一次性增加 20-30% 的流通供給,這種情況常見於早期投資人的大額懸崖期集中在同一天到期),對價格的潛在衝擊會大很多。

具體該怎麼做:在投資任何代幣之前,查一下這個項目的 Vesting Schedule 公開資訊(多數項目會在官網或區塊鏈瀏覽器上公開這份時間表),記下未來幾次重大解鎖的日期和規模,把這些日期標記起來,在做買賣決策時納入考量——不是說解鎖前一定要賣、解鎖後一定要買,而是至少要知道「這個日期附近,市場可能會有額外的賣壓」這個資訊,再結合你自己對項目基本面的判斷做決策。

為什麼懸崖期（Cliff）通常設計成 6 個月到 1 年，而不是更短或更長？這個時間長度是怎麼決定的？

懸崖期長度的設計,本質上是在「留住有價值貢獻者」和「不要過度限制流動性」這兩個目標之間找平衡點,6 個月到 1 年是業界摸索出來的一個常見區間,但不是絕對標準,背後有幾個具體考量。

太短的懸崖期(例如 1-2 個月)起不到篩選作用。懸崖期的核心目的,是確保只有真正打算長期投入的人,才能拿到代幣——如果懸崖期太短,一個人可能加入團隊沒多久、還沒真正產生實質貢獻,就已經開始解鎖代幣,這等於沒有達到「篩選長期貢獻者」的效果,任何短期加入又離開的人都能拿到部分代幣。

太長的懸崖期(例如 3 年以上)則會製造招募上的障礙。如果一個團隊成員或早期貢獻者,要等 3 年完全沒有任何代幣可拿,對很多人而言這個等待期太長,可能會降低他們加入的意願,尤其是在人才市場競爭激烈的情況下,懸崖期設計得過於嚴苛,反而讓項目在早期難以吸引到優秀的人才。

6 個月到 1 年這個區間的具體邏輯:通常對應到「一個新人大概需要多久才能被判斷是否真正適合這個團隊、是否會長期留下來」這個實務觀察——多數團隊的經驗是,一個人加入後,6 個月到 1 年內,通常就能看出這個人是不是真的投入、是不是打算長期做下去,這個時間長度既足夠篩選掉短期投機或不適合的人,又不會長到讓真正有價值的人才因為等待期過長而卻步。

不同角色的懸崖期設計也可能不同:團隊成員的懸崖期,有時會比早期投資人的懸崖期更長(因為團隊成員的「長期投入承諾」對項目的重要性,通常被認為高於單純提供資金的投資人),這代表懸崖期的長度不是一個放諸四海皆準的數字,而是需要根據「這個角色對項目長期成功的重要性」和「這個角色的市場競爭替代性」兩個因素,做出具體的權衡設計。

如果我是 Agent Token 項目的開發者，設計質押獎勵的 Vesting Schedule 時，和設計團隊/投資人的 Vesting Schedule，思考邏輯上有什麼不同？

兩者的核心目的不同,質押獎勵的 Vesting 設計,應該回答的問題是「怎麼確保質押行為反映的是真實的長期信心,而不是短期套利」,而不是團隊/投資人 Vesting 那種「篩選長期貢獻者」的邏輯,具體差異在三個地方。

目標對象的行為模式不同。團隊和投資人通常是少數、可識別的個體,懸崖期加線性解鎖的設計相對單純;質押獎勵的對象是大量、匿名的一般用戶,這些用戶質押的動機和行為模式差異很大——有些人是真心看好項目長期發展才質押,有些人可能只是想套利當下的高年化報酬率,拿到獎勵就想立刻脫手,設計 Vesting Schedule 時要考慮到這種行為的異質性,而不是假設所有質押者都有相同的動機。

常見的設計差異:質押獎勵的 Vesting,除了懸崖期加線性解鎖這個基本模型之外,常見的變形設計還包括「提前解鎖但要付出懲罰性代價」(例如用戶可以選擇提前解鎖,但要犧牲一部分獎勵作為代價,懲罰比例通常隨著提前解鎖的時間點越早而越高),這種設計比團隊/投資人的 Vesting(通常是硬性規定、不能提前解鎖)更有彈性,因為質押獎勵面對的是大量用戶,提供一定的靈活性,能提升整體參與意願,不會因為過度僵化的規則嚇跑潛在的質押者。

動態調整的可能性也不同。團隊/投資人的 Vesting Schedule,一旦寫進智能合約部署上鏈,通常被視為不可更改的承諾(改變規則會嚴重損害信任);質押獎勵的 Vesting 參數,相對而言更常被設計成可以透過治理機制動態調整(例如透過前面 Token Utility 詞條提到的治理投票,調整未來新增質押的解鎖速度),因為質押獎勵機制本身,常常需要根據市場條件、代幣通膨壓力做動態校正,而不是一次設定就固定不變。

設計質押 Vesting 時的核心判斷:你要解決的問題是「怎麼讓短期套利者的獲利空間降到最低,同時不過度犧牲真心長期質押者的體驗」,這是一個持續需要根據實際質押行為數據調整的動態設計,不像團隊/投資人 Vesting 那樣,設定好之後基本上不太需要再調整。

Agent 系統如果需要自動化管理一個代幣項目的資金運作（例如國庫管理 Agent），需要讀取或處理 Vesting Schedule 相關的鏈上資料時，有什麼特別要注意的地方？

這個場景結合了前面討論過的幾個原則,值得特別注意的地方主要有三個。

第一,Vesting Schedule 資料本身通常是公開、不可竄改的鏈上資料,但解讀時仍需要交叉確認。國庫管理 Agent 讀取 Vesting Schedule 相關資料時(例如查詢「未來 30 天內有多少代幣即將解鎖」),雖然這類資料本身來自智能合約、可信度較高(不像前面 Prompt Injection 詞條討論的、任何人都能寫入的公開資料),但仍然建議對接多個獨立的資料來源做交叉驗證(例如同時查詢區塊鏈瀏覽器和專門追蹤解鎖排程的第三方服務),因為偶爾會發生資料來源本身的解析錯誤或更新延遲,如果 Agent 只依賴單一資料來源做重大決策(例如根據解鎖規模判斷是否要調整國庫的資產配置),資料來源本身的錯誤會直接影響決策品質。

第二,國庫管理涉及的操作通常屬於高風險、高金額等級,應該套用前面最小權限詞條討論過的分層授權設計。如果 Agent 判斷「即將有大量代幣解鎖,建議調整國庫的穩定幣配置比例」,這類判斷可以由 Agent 自動產生建議,但實際執行(真正移動資金)應該保留人工確認這道防線,尤其是操作規模超過某個門檻時,不應該讓 Agent 完全自主執行,這呼應了前面反覆討論過的「高風險、不可逆操作,無論 Agent 的判斷邏輯看起來多合理,都要有人工確認」這個原則。

第三,解鎖排程本身的解讀,涉及一定的市場判斷,Agent 給出的結論應該附帶信心分數和依據,而不是直接下達確定性指令。前面提到,解鎖對價格的實際影響,取決於「解鎖規模相對於當前流通量的佔比」這類需要綜合判斷的因素,不是一個機械的規則(例如「只要有解鎖就一定要賣出部分資產避險」這種過度簡化的規則,容易在不同市場情境下做出不恰當的判斷)。國庫管理 Agent 給出的建議,應該用前面 Structured Output 詞條提到的方式,附上具體依據(這次解鎖規模是多少、佔流通量比例多少、歷史上類似規模的解鎖對價格的影響模式),讓人工決策者能理解建議背後的邏輯,而不只是接收一個「建議賣出」或「建議持有」的黑盒結論。