Monitoring Stellar with Hypernative

Why Should I Monitor

In the blockchain space, attacks can happen quickly, exploits can drain funds, and unidentified anomalies can become losses in the span of one block. Active monitoring helps to identify those anomalies, alert on them, and take action on them before they have a chance to become the next catastrophic loss. You wouldn't drive your car without a speedometer, you wouldn't fly a plane without instruments, and you shouldn't run a protocol onchain without active monitoring.

What Should I Monitor

Once we've established that we need monitoring, the common next question is “what do I monitor.” We call this “what to monitor and how” a “monitoring plan.” We have a tutorial available here to show how to stand one up in detail, but the monitoring plan follows directly from the threat model. A threat model asks the questions “What can go wrong?” and “What do we do about it?” The monitoring plan asks “How do we detect if something does go wrong?” and “What actions should we take?” So answering these questions is like building a model with building blocks.

• STRIDE Model
  • What are we working on?
  • What can go wrong?
  • What are we going to do about it?
  • Did we do a good job?
• Monitoring Plan
  • How do we detect if something goes wrong?
  • How do we action in that event?

What Does This All Look Like

While every STRIDE model and monitoring plan are unique to the project and risk appetite for the project, we can show how to set up monitors that can meet your requirements. Below are two examples that show how to set up a monitor in Hypernative, how to set up alerting, and what those alerts actually look like in real life.

Setting Up a Large XLM Transfer Monitor

Scenario

You have established a wallet on Stellar and set it as the source for all project-related fund transfers. You want to be notified any time a significant number of Lumens are transferred from that wallet for accounting and tracking purposes.

Setup

For this monitor, we will configure a custom agent in Hypernative and we'll choose “Address Transfer Activity” as the monitor type under “Address monitoring”.

On the following screen:

• Add the name of the monitor
• Assign a severity
• Set the chain to “Stellar”
• Set the monitored address “is one of” to your wallet address
• Set the counter-party to “is any”
• Set the token “is” to XLM (notice you can do any token, not just native here)
• Then set the filters to be what you consider “significant”

The end result should look something like this:

Click Next and configure your alerting actions. Here you can see I've chosen to set an email alert. After that choose Save.

While we have chosen to use email delivery as the alerting method, there are many more options including Slack, Discord, and Telegram notifications, kicking off incident.io incidents, and even contract invocations to run onchain events.

I ran a test transaction of 6 XLM to a test account to show the alert email that gets fired:

Setting Up Pool Utilization Monitoring on Blend

Setting up a basic monitor in Hypernative like large native transfers is relatively straightforward. But arguably it is a simple event. Hypernative also allows for monitoring higher complexity onchain events.

Scenario

You have established a position in a Blend lending pool. Your internal risk tolerance requires that you exit a pool with significantly high utilization to limit exposure to large swings in token valuation.

Setup

We will be configuring another custom agent, but this time, using the blank agent builder.

First, we need to select a trigger, which will tell our agent to run. Here, I chose a time-based trigger and fire this calculation at every block.

In order to calculate the utilization of a Blend pool, Blend's documentation directs that we calculate utilization with the formula:

Each of these values needs to be read from the contract state at each invocation time.

We set up four “Read Contract” blocks, all reading the lending pool contract and extracting out the different variables needed for this formula.

For each of the four variables:

• Select Stellar for the chain
• Select the contract address of the lending pool
• Fetch the ABI for the contract
• Set the function to get_reserve()
• Select the address of the asset to monitor for

• Set the Block Offset to 0
• Look at the output parameters from the function call to identify the value you need for the formula (in this case we grabbed d_supply).
• Set the output variable name for this value that you will use later in the agent.

Repeat the “Read Contract” block process for each of the four variables in the formula.

Next, connect all four of those to a calculation block.

This is where we implement the formula.

Notice I set my output variable of that calculation to “myUtil”. We'll use that in the next step.

Next we add an alert condition block. This filters the alerting to only what concerns me. Note that we scaled the “myUtil” number to be a percentage, since the calculation renders “1” as full utilization.

Finally, we use a send alert block to publish this event with our calculated values if this passes our filter.

Conclusion

Monitoring assets, positions, and actions onchain is important and beneficial. Hypernative enables deep level monitoring at scale on Stellar. While this document covered several different example scenarios, these monitors and documentation are provided for educational purposes only. Do your own research for contracts, monitors, triggers, and event conditions specific to your company and risk appetite. Hypernative has provided Stellar-specific documentation for how to implement monitoring and controls, available (authenticated) at https://docs.hypernative.xyz/hypernative-product-docs/hypernative-web-application/chain-specific-considerations/stellar.