Deploying Forta Bots with Gnosis Safe

With the flurry of new software flying around the Web3 ecosystem, the form of question that frequently comes up is: Can I do X with Y?

As with most software challenges, the answer is a resounding “Probably?” Another way to look at it is reflected in the response a former colleague shared from his graduate school advisor: It’s all a simple matter of programming.

In working with multiple protocol teams, we have found that several prefer to operate as decentralized as possible, and this presented us with an interesting challenge — to see if Forta Bots can be deployed by a multi-signature wallet instead of a single user EOA.

First, let’s provide a little background for each of these technologies.

Forta Bots

The Forta Network is a run-time security monitoring platform for decentralized finance. The network consists of Scan Nodes, which are servers that listen for newly mined blocks and transactions on one or more blockchains and then pass that data on to individual Bots that monitor for anomalous activity. The Bots are really just Docker containers running on the Scan Nodes, where inside each container a script is executed against blockchain data and returns alerts to the Scan Node to then be published to a database. Deploying a new Bot with an externally owned account (EOA) is fairly straightforward because most of the heavy lifting is handled by the Forta Bot SDK. To deploy a Bot with a smart contract will require us to break open the SDK and perform several steps manually.

Gnosis Safe

A Gnosis Safe is a smart contract that requires multiple signatures to perform transactions. Rather than storing funds in an EOA, which would require trusting a single user to protect a private key, a multi-signature system such as Gnosis Safe can spread the required trust among multiple users. Any transactions may be proposed by the owners of that Gnosis Safe and then either approved or rejected by a set number of those owners.

For example, if the owners of a Gnosis Safe would like to transfer tokens to another smart contract, one owner may propose that transaction and send the transaction to the Gnosis Safe. By proposing the transaction, that owner will have automatically provided the first approval signature. If the threshold for executing the transaction is 3-of-5 owners, then a total of 3 owners must provide their approvals before the transaction can be executed. Assuming 2 other owners provide approvals, which is performed by signing the proposed transaction with their EOA private keys, then the proposal is approved and ready for execution. Any owner may then execute the approved transaction, where the transaction will be performed by the Gnosis Safe smart contract itself.

Key Concerns 😉

In normal usage, the command npm run publishin the Forta Bot SDK will perform all necessary steps for deploying a Bot to the Forta Network. We will need to look behind the scenes to see what that command is kicking off:

1. Build a Docker image
2. Upload the image to the Forta Disco image repository
3. Upload documentation to IPFS
4. Create a manifest, sign the manifest with a private key, then upload the manifest and signature to IPFS
5. Call the createAgent method on the Forta AgentRegistry contract on Polygon

Steps 1 through 3 don’t involve any private keys or digital signatures, so they don’t provide any real obstacles to this effort.

Step 5 is the transaction that we will ultimately need to submit to the Gnosis Safe smart contract, so we are able to avoid needing a private key there.

The real question is: What do we do with the digital signature in step 4?

We asked the Forta Core Development team about this, and their response was that the manifest signature is to establish the provenance, or origin, of the Bot image that has been uploaded to the image repository. For our purposes, this means that we can use whatever private key we would like to sign the manifest without concerns that it may affect the Bot deployment process. In a production scenario, it would be up to the Gnosis Safe owners to check the signature, verify the signing address against a list of trusted addresses, and incorporate that information into their proposal approval process.

Deploy a Gnosis Safe

Now we’re going to deploy a Gnosis Safe smart contract to Polygon in preparation for deploying our Forta Bot. If you already have a Gnosis Safe deployed, feel free to skip to the next section. If not, read on.

There is a great guide available on the Gnosis Safe repository for using their SDK. Many of the steps here will use the code patterns and functions found there. Alternatively, you may decide to use the Web UI to deploy your safe.

We’ve created a script that should accelerate your deployment of a Gnosis Safe. All you need to provide is:

1. A .env file for storing your JSON-RPC endpoint URL and the private key for the deploying address you would like to use (please DO NOT commit this file to any repository)
2. A config.json file containing all of the Safe configuration parameters (owners’ addresses, number of signatures required for approval, Safe version number)

Ensure that the deploying address has enough MATIC and then use the command npm run deploy to deploy the Gnosis Safe. Be certain that you save the deployed address for future use.

Propose the Deployment of a Forta Bot

This is where the magic happens. But first, we need to have a Forta Bot ready to deploy. Our repository contains an example Bot that monitors the Forta AgentRegistry contract (we couldn’t resist the meta aspect…a Forta Bot monitoring the Forta contract that deploys the Forta Bot). That existing example Bot code can be removed and replaced with whatever Bot you would like to deploy.

If you already have a Bot developed (agent script, test script, documentation, etc.), you should only need to perform the following steps to get it ready for deployment:

• Clone our example repository
• Navigate to the gnosis-safe-deploy directory
• Copy your Bot src directory over the src directory in the example
• Copy your Bot Dockerfile over the example Dockerfile
• Copy yourREADME.md over the example README.md
• Copy your forta.config.json file into the example (for local testing)
• Update the example package.json file with whatever npm packages your Bot needs
• Copy the private key of one of the Gnosis Safe owners into the .env file with the name OWNER_ONE_PRIVATE_KEY. This account does not need any MATIC to propose a transaction.
• Ensure that you have a Forta keyfile in your ~/.forta/ directory. This file will contain the private key that will sign the manifest that is created during the Bot deployment process. If you have already deployed Forta Bots in the past, you most likely already have a keyfile in the right place. If not, you’ll need to create one.

With all of those elements in place, run npm run propose and the appropriate script should perform all of the same steps that npm run publish normally would, but instead of performing a blockchain transaction, it will propose that transaction to the Gnosis Safe using the Safe Service Client SDK. Once successfully proposed, the transaction can be viewed through the the Gnosis Safe Web UI or by directly interacting with the Gnosis Safe Transaction Service API.

Approve the Proposal

The most straightforward way to approve the transaction will be through the Gnosis Safe Web UI. The transaction dashboard is very easy to understand and use, so we recommend using the UI at this point.

However, if you still prefer the programmatic approach, we have another script that will allow you to approve pending transactions. To use it, you will need to update two values in your .env file:

• Add the private key of the owner who will be signing the proposed transaction to approve it. The corresponding name of that key will need to be loaded as the variable ownerPrivateKey inside the script.
• Add the Safe transaction hash and ensure that it is loaded into the variable safeTxHash in the script.

This approval process does not require any MATIC in the approving owner’s account. Whether approved through the Web UI or the API, the approvals should show up in both places. Once the required number of approvals has been reached, the transaction is ready to be executed by one of the owners.

Execute the Transaction

Now there’s some good news and some bad news ahead.

The good news is that you’re only one step away from deploying your Forta Bot to the Forta Network.

The bad news is that the success of this blockchain transaction will be highly dependent on whether any NFT drops are currently occurring on Polygon, whether your preferred JSON-RPC provider is currently down, as it was for Infura on the day of this writing, or if there are many transactions occurring from blockchain games.

Unfortunately, these situations can cause various error messages to appear in both the Gnosis Safe UI and in MetaMask when attempting to execute the transaction. The root cause appears to be the inability of a Gnosis Safe or MetaMask to appropriately estimate gas costs during periods of high activity, although manually setting the gas price doesn’t remedy the issue. We ultimately had to wait for the high transaction activity to subside before reattempting to execute our transaction, at which point the Forta Bot was successfully deployed.

Go Forth and Monitor

If you have followed the steps in the previous sections, you should have successfully deployed a Forta Bot. Well done!

You may now pass on your Bot’s ID to others so they may subscribe to the alerts that your Bot produces. You may find that your Bot is not performing as you expect, which means you’ll need to maintain and manage it. But that brings us to…

Caveats

The deployment of the Forta Bot is represented by an ERC721 token issued by the Forta AgentRegistry contract on Polygon to the deploying address. That address is also used by the Forta App for managing the deployed Bot through their web interface. Unfortunately, the authentication method for the Bot management dashboard requires a digital signature using the deploying private key that corresponds to that address. Now that the deploying account is a smart contract, there is no private key. Therefore, while the Bot can be viewed on Forta Explorer, it cannot currently be managed through the Forta App.

The lack of management through the UI seems appropriate, as now the Forta Bot belongs to the Gnosis Safe owners (i.e. we wouldn’t want a single owner to unilaterally change the Bot’s status). Therefore, we could write additional scripts to perform the disable, enable, and update actions on the Bot, propose them as transactions to the Gnosis Safe, and then allow owners to approve and execute, or reject, the proposals.

This was tested for Gnosis Safe version 1.3.0, so your mileage may vary for the earlier versions.

Note About Polygon

Interacting with Polygon was more than a little frustrating. Just to deploy the Gnosis Safe contract (really, deploying a proxy to the implementation) led to much consternation until finding this helpful post that indicated that we might want to raise the gas price specified in the transaction. That turned out to not be enough later when we wanted to execute an approved transaction with the Gnosis Safe, as gas had soared to over 200 gwei during a period of particularly high Aavegotchi transaction volume combined with other Polygon based blockchain games. The errors returned either from the command line using ethers.js or from the Gnosis Safe Web UI and MetaMask were unfortunately too vague to be helpful, or possibly even a bit misleading. In the end, the drop in heavy activity allowed all transactions to flow easily. That is to say, if you encounter difficulties, stick with it!

Looking for smart contract audits, training, or other decentralized technology security services? Check us out at arbitraryexecution.com.