🤖 beep boop 🤖 welcome to gitter.network

Easily build automated dApps with the gitter.network automation protocol


Imagine a scenario where you would like to transfer some of your accumulated GAS from your wallet to flamingo to stake every week. 80% of that GAS should go to pool A, 10% to pool B, and the remaining 10% to pool C. At the same time, you might want to re-stake the accumulated rewards when they reach a specific amount. Doing all the transfers and staking actions every week could quickly become a nuisance. Constant monitoring is required, and let's be honest, repeatedly doing the same work is just tedious.

The situation described above is just one of endless examples that could, and should be automated.

Other examples: Liquidation protection in lending protocols, Limit Buy/Sell Orders, etc.

Unfortunately, smart contracts are not as smart as they seem; they can't trigger logic themselves when a specific condition is met. Instead, they define a certain logic and state and rely on a transaction sent to them to execute something.

Nothing will happen if no one ever sends a transaction to the smart contract. A naive approach is to put all the logic into an endless loop, but the gas costs will prevent any smart contract from running long enough to make this even remotely a viable solution.

So how can this problem be solved? How can one easily automate their dApps and ensure that all the methods will automatically execute on time?

The answer is that it's not easily possible. At least not with web 2.0. You would need countless cron-jobs, monitoring and notification tools, set up a database, ensure all the private keys are safe, have enough funds available to execute the transactions, etc. So this approach is not just a lot of work and error-prone but also not very scaleable. Also, it will be a single point of failure.

And this is where the gitter.network, a decentralized smart contract automation network comes to the rescue.

What it does

gitter.network is a decentralized automation protocol built on the NEO N3 blockchain. It allows a reliable automatic execution of arbitrary smart contract logic with the help of a decentralized execution infrastructure.

With gitter.network anyone can automate their smart contract method in just a few steps. It's reliable, fully decentralized, and straightforward to use. Moreover, you don't need to be a developer to set up the automation job. Instead, provide the smart contracts with the necessary information, and the executors will take care of the rest and execute the job on your behalf. The job creator only has to ensure that enough funds are in the gitter treasury to pay the executing entity.

To create a job, you need to answer the following "what? when? how?" questions.

What function of which smart contract do you want to automate? Provide the smart contract with a valid contract script hash and a method with its parameters if existent. Additionally, you could pass a resolver hash if you prefer to work with dynamic over static inputs—more about this in the section below.

When do you want to execute the function? Every block? Every 5 minutes or every Friday at 6 pm? The minimum execution interval is 15 seconds which is the approximate block time on NEO. The gitter protocol accepts a starting- and an interval time. If you work with resolvers, you won't need to provide this information as they are responsible for when your method is ready to be executed.

How do you want to pay for the execution? You can only fill your treasury balance with the GAS token in the initial version. In the future, you can choose to pay the executors with the official gitter.network GIT token.

After the job creation, the executors will periodically perform a check on your job and execute it as soon as the conditions are met. There will be a system in place to fairly distribute the jobs among all the executors. The job creators pay the GAS fee for each execution, consisting of the transaction fee + execution fee, of which the latter will be governed by the gitter DAO. The gitter protocol takes care of the payments, so the GAS is transferred automatically after each successful execution from the creators' treasury balance to the executor wallet. The goal is that anyone will be able to run an executor bot to create a fully decentralized bot network. I wrote a simple executor bot in java for the hackathon entry that executes timed jobs every block.


In some cases, the job creators do not know the parameters of the functions they would like to automate. Let us look at an example where one wants to create a buy limit order on the flamingo's GAS/bNEO pool with the help of the gitter protocol. When the GAS price drops below a certain point, the job creator wants to swap 50% of all their available bNEO for GAS. In a scenario like this, we might now know exactly how much 50% will be. So, it makes sense to write and use a resolver contract.

A resolver contract is a smart contract in which job creators can write their logic of "when" an execution should happen and what data executors should use for the execution. The executors will then only execute the job when the condition in the resolver allows it.

To use a resolver contract, you skip the start- and interval time and instead pass the script hash of the resolver. The resolver method must return either an empty array when no execution is possible or an array with the parameters that will be passed to the method that the executors will call.

The hackathon prototype does not support resolver contracts yet, but it will be one of the first milestones on the roadmap.

How we built it

The project consists of smart contracts, a frontend web application, and a spring boot application.

Smart Contracts

For now, there are two different smart contracts: gitter-core and gitter-treasury. The gitter-treasury is responsible for holding the deposits of the job creators, adding to- and removing from their balance. The gitter-core contract takes care of all the rest, such as job creation, job execution, etc. All the smart contracts are writting with neow3j.


The frontend web application is a SPA written with angular. It also uses Neon.js and NeoLine to interact with the blockchain and sign transactions).


For the executor bot I used java (spring boot) and neow3j.

Challenges we ran into

It was a challenge to develop a way to determine if a user's treasury balance was high enough for the executor to execute it. But in the end I figured out a way and could apply a relatively simple solution.

Accomplishments that we're proud of

I am very proud of what I have accomplished in such a short time: a working prototype that could turn into something quite powerful from what many developers on NEO N3 could profit. There are many valuable use-cases for an automation protocol, and I am happy to share a working solution with the community. I am also pretty happy with how the initial frontend design turned out.

What we learned

I worked a bit more than usual with neon.js, so I learned some new things about this library - functions that I didn't know before but are pretty helpful.

What's next for gitter.network

I hope to find maybe 1 or 2 more developers that want to support me in bringing this project forward. Having a bigger team would speed up the process of completing the following milestones:

  • add support for resolvers
  • add support for more time intervals
  • set up a proper bot network infrastructure
  • improve current executor bot
  • introduce the GIT token, which will act as a governance token and can be used f.e. to vote on executor fees. Or it can be used as collateral when wanting to run an executor bot.

Testnet Script Hashes

Contract Script Hash
Gitter Treasury 0xcd8ddb5a1add6191d427a5692fafdf28a3467f81
Gitter Core 0xb67c208b0a66abdbe4c18088a927890aac6fa084

Additional Info

App: https://gitter.network (NeoLine required)

Don't forget to start the executor bot application before creating a job. Alternatively, you can text me on the official NEO discord (Fireche#1404), and I will gladly start a bot. When trying to run the bot yourselves follow these steps first:

  1. copy the application.yml and rename the new file to application-test.yml.
  2. fill in the executor wallet WIF
  3. run the application with: spring-boot:run -Dspring-boot.run.profiles=test
  4. make sure that the executor wallet has some GAS in it

Built With

Share this project: