出于安全考虑，批准按域以及批准地址（即批准（批准，域，金额））键入。否则，恶意行为体可以使用colony中的任何仲裁许可持有人来削减stake，而不是使用预期域继承路径中的仲裁许可持有人。然而，由于TokenLocking不知道特定colony的域结构，TokenLocking中的义务是所有colony和域特定义务的集合。

　　总的来说，这种设计允许将仲裁广义化，并将其与任何特定扩展的实施分离开来：扩展名指定了权益（并界定义务期限），而在这一期间，单独的仲裁程序可以削减该利害关系。

　　2.7可升级性和安全性

　　2.7.1可升级性

　　我们预见到群体网络将不断发展。提供一个升级路径对于允许人们使用Colony而不阻止他们自己使用添加到网络中的新功能是很重要的。我们打算允许colony和代币通过使用以太路由器名称下提供的模式进行升级。除了提供实现的功能的合约之外，此实现还使用两个合约。第一个附加合约是EtherRouter合约，它通过delegatecall将事务传递给实现该功能的合约。第二个附加合约是解析器合约，其中定义了实现所需行为的合约的帐户。每当EtherRouter协定接收到事务时，它都会在解析器中查找实现该功能的协定（如果有的话），然后delegatecalls该协定。为了升级，使用新功能部署新合约，然后必须更改解析器合约指向的合约以指向这些新合约。为了避免合约部分实现新旧功能的情况，每次升级都会部署一个新的解析器实例，然后一个事务可以将EtherRouter指向新的解析器。从colony的角度来看，升级就是简单地将一个地址（解析器）换成另一个地址。

　　升级底层colony合约的选择总是落在colony身上，而不是落在colony网络上。虽然网络可以控制哪些升级可用，但他们无法强制任何colony升级基础合约。colony本身必须决定要升级到新版本。

　　2.7.2安全

　　虽然我们渴望无bug的合约，但是bug是不可避免的，因此采用“防御编程”的心态将限制在已部署合约中可能发现的任何漏洞的影响。

　　最终的回退被称为“恢复模式”。在这种状态下，白名单帐户（具有恢复权限的帐户）能够访问允许直接编辑合约状态的特殊功能—实际上，这将对应于访问允许设置变量的功能，以及能够升级合约。在多个白名单账户的同意下，一旦合约恢复到安全状态，合约就可以退出恢复模式。从恢复模式中删除需要多个白名单帐户的批准。这样可以确保单个白名单帐户在单个事务中不能进入恢复模式，进行恶意编辑，然后在白名单上的其他方有机会作出反应之前退出恢复模式。

　　可以想象，一旦网络和合约足够成熟，colony将能够在未来停用恢复模式功能。