Additional security dapp for monitoring legitimate teleportations
It's no secret that security issues leading to various hacks over the years have plagued cross-chain messaging protocols. Typically an attacker figures out how to fake a cross-chain message which enables them to steal collateral or mint unbacked tokens.
We feel that these attacks - however sophisticated in nature - can be easily stopped in their tracks with the addition of some simple contract monitoring infrastrcuture.
How it works
Teleportation of d2o works by burning d2o on one source network and re-minting it on another destination network. The instruction to re-mint d2o is transferred from one network to another by a cross-chain messaging protocol.
Under normal circumstances, mint operations on a destination blockchain network must follow a burn operation on a source blockchain network. This is a protocol invariant, and so any mint operation observed in isolation can be immediately flagged as a potential issue.
Burn and mint events can be monitored in real-time by a decentralized guardian application, which is highly available, durable and provide coverage for all networks d2o is deployed to.
In the event the guardian encounters a mint in isolation, it would pause the account in question – whereby the newly minted tokens cannot be transferred – so a community-based investigation can be carried out. The d2o tokens at this point are temporarily frozen until the community stewards are satisified that no potential exploid has occured. As such, account can be quickly unfrozen so the tokens can be moved again.
Trade off sand tail events
It's worth noting that the dGuardian exists to defend against highly unlikely but potentially catastrophic tail events.
We can probably all agree that no d2o holders would not want the token be exploited due to weaknesses in the underlying messaging protocols, therefore, even though the expecation of this is low, it makes sense to defend against it as everyone loses out it if happens.
The solution requires cedeing some decentralisation to the dGuardian oeprators. Whereby the dGuardain has the means to freeze a d2o account if its algorithm thinks it is necessary to do so.
It might be the case that false positives happen and accounts are unecessarily frozen. If so, they can be promptly unfrozen either by the Guardian itself (if the issue was due to incorrect ordering of burn and mint events), or by a protocol steward. We realise it's disconcerting if this happens but the control is there to protect everyone.
Currently, the dGuardian only interacts with d2o contracts however there is scope for extending it in the future.
Other applications or services using d2o can subscribe to security alert messages regarding the token. For example, consumers of these messages may wish to freeze liquidity pools for the token in question if there is reason to suggest fraudulently minted tokens might have been deposited.
We call this the dGuardian and it is a key detective control to ensure that teleported assets remain a safe and secure medium of exchange for its users.
Whilst our token contracts have been audited and we are confident in their integrity, we feel strongly in relying on additional controls as there is always a non-zero chance of an attacker finding an exploitable vulnerability in any of the software stack used to implement the token.
The dGuardian has a simple website available here, which shows protocol stats, the currently monotored networks, as well as any in progress teleports and if there are any exceptions.
Note that there are multiple instances of the Guardian running.