Telepathy's approach to trust-minimized administrative functionality.
Telepathy attempts to minimize trust assumptions in the protocol by reducing the amount of permissioned functionality to only essential administrative actions. With a transparent overview of access control in Telepathy, you can be informed and fully understand the security implications of using Telepathy.
To provide a reliable arbitrary message bridge that
- Protects user applications in the case that an exploit is found
- Stays up-to-date with future updates to the Ethereum protocol
function freeze(uint32 chainId) external onlyGuardian
or all chains simultaneously:
function freezeAll() external onlyGuardian
This safety mechanism allows a potential issues to be mitigated and functionality to resume with minimal interruption. This mechanism is only intended to be called by the Guardian multisig if an exploit is suspected or found. As the protocol matures, we intend on removing this permissioned functionality.
The Telepathy Router is currently upgradable. Similar to how rollups need upgradeability for changes in the Ethereum execution layer, our protocol requires upgradeability for changes in the Ethereum consensus layer. In the short-term, we believe that upgradeability should only be allowed via a Timelock, meaning that the execution of these upgrades only occur after a predetermined amount of time has passed. Our current timelock period is 7 days and controlled by the Succinct Guardian Gnosis SAFE. This time delay adds transparency to the administrative actions being taken and users can verify that the changes are not malicious. Any stakeholders that do not agree with the upgrades proposed can exit the protocol safely before it executes.
In the longer-term, we want to decentralize this upgradeability authority beyond the Succinct team.
_authorizeUpgrade(address newImplementation) internal override onlyTimelock