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

符合最新標準

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

目前接受的標準有：

· EIP20標準

· EIP721標準

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

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

防止將代幣傳輸到0x0地址

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

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

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

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

示例：

實施上述兩項建議的一個示例是創建以下修飾符；驗證“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 。..）

}

程序文件

當啟動一個將有大量資金或需要關鍵任務的智能合約時，必須包括適當的解釋文件和安全相關的文檔包括：

規格和推出計劃

· 規范，圖表，狀態機，模型和其他文檔，可幫助審核員，審閱者和社區了解系統的意圖。

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

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

狀態

· 當前代碼的部署位置。

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

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

· 已部署代碼的當前狀態（包括未決問題、性能統計等）

已知的問題

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

· 所有已知Bug/限制。

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

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

歷史記錄

· 測試（包括使用情況統計信息，發現的Bug，測試時間）。

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

緊急程序

· 發現Bug時的行動計劃（例如，緊急選項，公共通知流程等）。

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

· 負責任的披露政策（例如在何處報告發現的Bug，任何Bug賞金計劃的規則）。

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

聯系信息

· 誰來處理問題。

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

· 可以提問的聊天室。

來源： 區塊鏈研究實驗室