BUIDLHub v1.0.3 Released

A quick tutorial to stream Ethereum events to Discord messages in minutes

Mitchell Opatowsky

Published in

BUIDLHub

6 min readMar 8, 2020

So we released a new version of BUIDLHub this week… and you all loved it.

Let’s figure out what got Auryn Macmillan so hyped!

Discord Integration

Let’s work on one example for now: Civil.

Part 1: Activity on Civil Contracts

Civil is a Consensys formation project focused on building community-operated journalism networks based on transparency. They feature their smart contracts on their website in this elegant fashion:

see here: https://civil.co/contract-addresses. I feel like this should be the industry standard.

The contracts with the most activity are their CVL Token Contract and their PLCR Voting Contract. Fortunately for you/me, the ABIs (Application Binary Interfaces) that serve as the Rosetta Stone in some senses for their contracts are publicly accessible from Etherscan.

Let’s say I want to listen for activity on these contracts. The Civil app isn’t publicly available on BUILDHub just yet. Currently, we feature a subset of the ENS contract as a start. Since our goal is all about ease of use and experimentation, we’re going to onboard & integrate far more dapps and services. You can help this list of dapp connections by expanding it!

First, I signed in with BUIDLHub using Github OAuth.

After I signed in, I clicked on “Connect an App”, as we’ll be building our version of Civil for reuse and to integrate into our flows.

If this is the first app you’re connecting, you’ll be given a form of metadata fields to submit. I uploaded an app icon and added some strings.

Save it.

First, we’re going to add a connector. This is contract information — where we get the essential ABI to interpret.

Select an Ethereum Smart Contract as the connector type and input the Ethereum address from before into the respective field. I’m using the CVL Token Contract Address here.

After I’ve added the above Connect, I’ll add an Alert.

This is the App Builder flow. Connector → Alerts/Query Functions. The right is an example of how this looks inside the flow designer to give you a reference of how this gets used. So Alerts can be used as Triggers in Flow Designer while Query Functions can be used Triggers or Actions.

When I’m in the Alerts editor, in Step 1. Let’s talk about what your options are:

Specific Function — If a function is detected
Specific Event — Events include things like token OwnershipTransferred, Approval, Transfer.
Any Transaction—Listens for any new firing on a contract.

Any Transaction

I select “Any Transaction” for my “Alert Trigger”. I can skip Step 2.

In Step 3. I can enter a basic name like “Any Civil Token Activity” and add a brief description in the short description field.

In Step 4. I can add Output Source Fields that serve as all the possible fields I can listen to in my flows. I’m given a nice output mappings breakdown as well.

(left) Choosing the fields to serve in the current output mappings (right). These are the data points I’m listening to.

Specific Event

Alternatively, as opposed to any transaction, I can select “Specific Event” for my “Alert Trigger”. This allows me to listen for a LogEvent as defined in the contract. Events are often emitted by the smart contracts when a user invokes the contract as part of a transaction. The contract author emits these events because they represent some significant state change within the contract logic. We subscribe to these state change events using this “Specific Event” alert mechanism.

Indicate the event of interest in Step 2 to set the required parameters.

Flow Designer

Let’s use it in a flow.

In Step 1, I navigate to the dropdown selection and look for the Civil app I just created. Step 2 populates with the relevant Alerts or Query Functions I can call from the app.

For a Specific Event, illustrating an alternative to Any Transaction Firing

In the second step, I’ll select Discord as my Action Source in Step 1, with the Action “Post Message to a Discord Channel” as my action.

The second step is where things get a little more interesting.

The first part asks me to grab my Discord Webhook URL. You can access this by creating a new webhook or using an existing webhook’s link from Discord, and you’ll need to be the admin of a server to have that.

I copy and paste the Webhook URL associated with the webhook back into BUIDLHub.

The second part of Step 2 asks me to create a Discord Post Body. You can use the + button to add output fields from any previous step in the flow.

I ended up printing a message like this:

New Activity from **CIVIL** token contract:
From: ${ctx.outputs.step1.from}
To: ${ctx.outputs.step1.to}.
Value: ${ctx.outputs.step1.value} ETH
Using this Gas: ${ctx.outputs.step1.receipt_gasUsed} Wei
See here **https://etherscan.io/tx/${ctx.outputs.step1.hash}**

Click “Save & Continue” and Start the Flow!

And that’s all there is to it!

Moving on from this article, what we can increasingly do better as a community is pushing dapps to feature their contract addresses on their websites (looking at you Maker). What we should also push for is to make ABI more publicly accessible. The whole reason we emphasize Ethereum over other permissioned chains is because of the public verification of activity. Public auditability is hampered when these ABIs could be outdated or the contract addresses don’t feature the ABI too. Let’s work together to make this the new norm.

Looking forward to what these next few months hold in store for us. Share us some of your love ❤️ in our chats to give us new ideas or reach out to us by email to suggest new integrations!

Use Eventflow for FREE to dramatically reduce the time on blockchain-based event integrations.

Please join our community here:

Twitter: https://twitter.com/BuidlHub
Medium: https://medium.com/buidlhub
LinkedIn: https://www.linkedin.com/company/buidlhub/
Telegram: https://t.me/buidlhub
Discord: https://discord.gg/fQtpeT2