代幣發(fā)布時應遵循其他最佳實踐經驗，但也要有一些獨特的注意事項。

符合最新標準

一般來說，代幣的智能合約應遵循公認且穩(wěn)定的標準。

目前接受的標準有：

· EIP20標準

· EIP721標準

注意在EIP-20上的前端攻擊

EIP-20令牌的approve（）函數(shù)為批準的支出者創(chuàng)造了超出預期金額的可能性?？梢允褂们岸斯?，使批準的支出者可以在處理對approve（）的調用之前和之后調用transferFrom（）。

防止將代幣傳輸?shù)?x0地址

在編寫本文時，“零”地址（0x0000000000000000000000000000000000000000）包含值超過8000萬美元的代幣。

防止將代幣傳傳輸合約地址

還要考慮防止代幣轉移到智能合約的同一地址。

EOS代幣智能合約就是其中一個可能造成損失的例子，其中超過90，000個代幣被卡在合約地址上。

示例：

實施上述兩項建議的一個示例是創(chuàng)建以下修飾符；驗證“to”地址既不是0x0也不是智能合約自己的地址：

modifier validDestinaTIon（ address to ） {

require（to ！= address（0x0））;

require（to ！= address（this） ）;

_;

}

然后將修飾符應用于“ transfer”和“ transferFrom”方法：

funcTIon transfer（address _to， uint _value）

validDesTInaTIon（_to）

returns （bool）

{

（。.. your logic 。..）

}

function transferFrom（address _from， address _to， uint _value）

validDestination（_to）

returns （bool）

{

（。.. your logic 。..）

}

程序文件

當啟動一個將有大量資金或需要關鍵任務的智能合約時，必須包括適當?shù)慕忉屛募桶踩嚓P的文檔包括：

規(guī)格和推出計劃

· 規(guī)范，圖表，狀態(tài)機，模型和其他文檔，可幫助審核員，審閱者和社區(qū)了解系統(tǒng)的意圖。

· 很多bug都可以從規(guī)范中找到，從而降低修復它們的成本。

· 推出計劃，其中包括此處列出的詳細信息以及目標日期。

狀態(tài)

· 當前代碼的部署位置。

· 編譯器版本，使用的標志以及用于驗證部署的字節(jié)碼的步驟與源代碼匹配

· 將用于不同階段的編譯器版本和標志

· 已部署代碼的當前狀態(tài)（包括未決問題、性能統(tǒng)計等）

已知的問題

· 智能合約的主要風險。 （例如， 你可能會丟掉所有的錢，黑客可能會通過投票支持某些結果）

· 所有已知Bug/限制。

· 潛在的攻擊和解決方法。

· 潛在的利益沖突。（例如，籌集的Ether將納入自己的腰包，像Slock.it與DAO一樣）

歷史記錄

· 測試（包括使用情況統(tǒng)計信息，發(fā)現(xiàn)的Bug，測試時間）。

· 已審閱代碼的人員（及其關鍵反饋）。

緊急程序

· 發(fā)現(xiàn)Bug時的行動計劃（例如，緊急選項，公共通知流程等）。

· 如果出現(xiàn)問題，請結束流程（例如出資者會在攻擊前從剩余資金中獲得余額的百分比）。

· 負責任的披露政策（例如在何處報告發(fā)現(xiàn)的Bug，任何Bug賞金計劃的規(guī)則）。

· 發(fā)生故障時的追索權（例如保險，罰款基金，無追索權）。

聯(lián)系信息

· 誰來處理問題。

· 程序員和/或其他重要人員的姓名。

· 可以提問的聊天室。

來源： 區(qū)塊鏈研究實驗室