Guardrails

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

some permissioned functionality is necessary. This functionality is limited to being called by the Guardian (a Gnosis Safe multisig) or the Timelock controller.

For a comprehensive list of the administrative functions, see TelepathyAccess.sol.

Freezing

In the event that a vulnerability is found (either in the Circuits or Contracts), Telepathy will pause the functionality of receiving messages in order to protect user applications. This may be on a per-chain basis:

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.

Upgradability

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.

Implementation

Our upgradeability uses the OpenZeppelin's UUPSUpgradeable pattern, which is an audited and standardized method for changing the implementation logic of contracts via:

_authorizeUpgrade(address newImplementation) internal override onlyTimelock

As mentioned, the upgrades are locked behind a Timelock controller, which means that the execution of these upgrades only occur after a predetermined amount of time has passed. Read more about why Timelocks are a principled approach to administration here.