Learn more about how MonitorChain works as the first on-chain Ethereum token security alert oracle.




The Simple Version

MonitorChain works to protect exchanges, traders, and token creators from cryptocurrency hack and theft related fraud. Rather than doing this in the way most security firms and smart contractor auditors do by attempting to prevent these incidents, MonitorChain springs to action once a catastrophic event has occurred to halt and mitigate the damages that occur in the aftermath of such hacks – specifically the dumping of stolen cryptocurrency tokens on DApps and exchanges to ‘fence’ their stolen goods, which passes the losses on to traders, exchanges, and token creators, resulting in the vast majority of hack related losses.

How does MonitorChain do this? By running a full Ethereum node, MonitorChain sees every single transaction and event that occurs on the Ethereum blockchain, including those on token contracts and decentralized applications that reside on Ethereum. With a combination of expertly crafted rules created by blockchain analysts and automated smart contract parsing engine, we have developed a system that detects suspicious activity the moment it occurs.

When a potential exploit or theft has occurred, MonitorChain sends the details of the incident to its subscribers so that they can take protective action. What makes MonitorChain different from other security feeds is that MonitorChain itself is on the Ethereum blockchain and was built specifically for use as an oracle in other smart contracts. What this means is that even decentralized applications like exchanges and tokens without an ‘owner’ can use MonitorChain to take automated protective action, securely and within seconds – before hackers dump hacked and stolen tokens on their users.

The Technical Version

MonitorChain is advanced security layer residing on top of the Ethereum blockchain. Given that preventing future problems with tokens and smart contracts, which are not fully covered by smart contract audits and that can include future found exploits and stolen private keys is of the highest importance, MonitorChain adds timely detection, alerting and prevention of the use of stolen tokens. Given that Ethereum tokens in most cases adhere to the token contract standard described in a handful of Ethereum Requests for Comment (most notably ERC20), it is possible to detect such token transactions and evaluate terms of their execution. Each token has specific set of functions and events that it must implement. Some of the most important are transfer and transferfrom functions as well as Transfer event. Extended ERC standards can also contain mint function and Mint event; therefore, it is possible to track whenever such function has been executed by listening to proper events that it emits. By listening, it is possible to apply rules which govern validation to all token transactions and based on the rules, specific token statuses can be inferred. MonitorChain utilizes accounted features of tokens smart contracts to implement the state-of-the-art token security solution on the Ethereum blockchain.

MonitorChain is comprised of the following components: MonitorChain Smart Contract (MCSC), Monitor, Tracker and AccessInterface library (AIL). MCSC is the main part of the MonitorChain system and is a central point of integration of the MonitorChain components. Information from all other components flow towards it, and stakeholders receive data by querying its functions. It serves as an Oracle that can be queried by other smart contracts or offchain applications to get information about the statuses of specific tokens or blocked addresses. Furthermore, it also controls access to the token statuses and blocked addresses and governs the process of token status changes. The Monitor is the component that listens, through a full Ethereum node endpoint provider for transaction related events that are submitted to the Ethereum blockchain. For each token transaction that is executed, Monitor performs transaction validation. Validation is based on the general token validation rules which include checking of the considerable total supply increase, transaction of an amount that exceeds sender’s balance, very big token transactions, and numerous additional scenario specific custom rules. The accounted rules are modeling the exploits that have already been discovered, and also covers most future exploits due to the narrow range of possible scenarios that occur once a hack is successful.

Given that each token smart contract has its own specific implementation, Monitor performs token specific validation. This includes change of a hard cap value predefined in the contract, violation of the token release rules encoded into the contract, massive transfers from the token reserve addresses and more. Such per token monitoring requires specific token smart contract audit and development of dedicated validation scripts. Based on the level of detected validation error, Monitor sends the status change to the MCSC that includes token address, error level and error description text. Error levels are currently defined in the following way: 0 – Good, 1 – Notice, 2 – Warning, 3 – Severe, 4 – Emergency. Once the problematic transaction has been detected by Monitor, it sends the transaction destination address to the MCSC and spawns the Tracker component. Tracker is responsible for tracking the transaction tree whose root is the detected problematic transaction destination address. During tracking, Tracker triages the involved addresses based on previous transactions of other tokens, interactions with well-known dApps and the transaction amount value to identify whether the address should be blocked. AIL is the helper library that should be utilized by MonitorChain users to access MCSC. It contains two parts, AIL contract, which implements the smart contract functions available for the client and AIL library that enables Node.js developers to call MonitorChain programmatically.

MonitorChain works in the following way (see images below): When a hacker performs a malicious transaction on a token smart contract, a transaction or mint event is emitted on the Ethereum blockchain. The Monitor component listens to such events on the Ethereum blockchain and catches the event related to the malicious transaction. After the Monitor detects that the transaction is failing validation, it performs series of actions. First action is updating the status of the token with a proper status level according to the severability of the detected problem. It adds the transaction destination address to the list of blocked addresses and spawns the Tracker by passing it the transaction destination address. Tracker continues to detect and add involved addresses to the list of blocked addresses on the MCSC.

After the token status has been changed on the MCSC, there are two main scenarios of subscriber interaction with the MC. In the first scenario, any smart contract can query MCSC asking it what the status of a specific token is. Based on the returned response, a smart contract can react properly. For example, if a decentralized exchange smart contact (DEX) is about to perform an exchange involving a token that was a subject of a hacker attack, it can ask MCSC about the status of the token. If MCSC responds to DEX that token’s status is other than Good, DEX will be able to cancel the transaction effectively preventing the potential hacked tokens to be exchanged for some other cryptocurrency.

The second scenario is based on the events that MCSC emits. Whenever a token status is changed, MCSC emits the event with a specific sequential number. A subscriber can query MCSC asking to which token the emitted event applies to. If the subscriber is subscribed to a token in question, it gets the token address. Subscriber can then ask what the new status of the returned token is. If a subscriber is an offchain DEX helper application that listens to the Ethereum events, it can block all transactions involving the token in question on the DEX smart contract by calling its transaction freeze function.

Process Flow Chart for Direct Integration


Process Flow Chart for Integration via External Admin Contract or Platform