Ocelloids SDK: Multi-chain Monitoring for Substrate

Ecosystem
1

Greetings everyone,

We’re thrilled to introduce Ocelloids, our multi-chain monitoring SDK tailored for Substrate networks and smart contracts. Explore it here: Ocelloids GitHub.

The highlights of Ocelloids SDK:

  • Composable Reactive Streams — Easily filter blockchain data and react to occurrences of interest using composable reactive streams.
  • Data Sources — Retrieve data from extrinsics, blocks, events and storage.
  • Powerful Query Operators — Filter data using integrated operators that support complex queries in the Mongo query language. Includes support for big numbers and advanced features such as dynamic queries.
  • Flexible Type Conversions — Seamlessly convert data into a terse queryable format.
  • Extended Context Types — Extend base generic events and extrinsics with contextual information such as block number, block position, extrinsic position, etc.
  • Abstraction of Common Patterns — Simplify development and reduce boilerplate code by abstracting common patterns such as utility batch calls.
  • Multi-Chain Support — Interact with multiple networks.
  • Pallet-Specific Modules — Modules designed to handle use cases related to a particular pallet, such as tracking calls and events from the contracts pallet.

We have some example applications that you can find here of some use cases that include:

  • Use with Smoldot
  • Monitor ink! contract messages
  • Track account balance fluctuations
  • Oversee sovereign accounts across parachains

Ocelloids SDK’s development was generously supported by the Web3 Foundation. At SO/DA zone, we’re dedicated to enhancing Ocelloids, envisioning a user-friendly monitoring portal for running and managing agents.

Our journey involves continuous enhancements and additions. Please drop us any feedback, suggestions, and criticisms that would help us to build a robust monitoring solution for the Substrate ecosystem.

Cheers,

SO/DA team

1 Like
2

Thanks for sharing this! I have a couple of questions:

  1. How do you envision this to be used by end users? do you expect anyone who uses this to write some code themselves? Easy configurability through JSON would be good.
  2. Or else, do you expect a team to pick this up, and build an end-user facing system on top of it?
  3. This reminds me of a toy project I made a couple of years ago, that more or less does the two questions I posed above:
  • An easy way to configure the system
  • Built-in reporters, ie. means or receiving the triggered event (email, telegram, matrix, etc)
  • Easy to self-host, so I always imagined everyone to host this themselves.

Perhaps if you take a look at some of my experiments, or the write-up here, it can help you find good next steps to make this something applicable.

All in all, I think the need for a multichain monitoring/notification system is essential in Polkadot, and I have not yet seen a solution that hits all the targets, at least not for my usecase.

I’d like to name some of my favorite projects though: Web3-Alert, Rayabina bots are both pretty useful for most cases. Wondering what other alternatives exist out there

3

Hi @kianenigma,

Glad to hear this and thank you for sharing your project and write-up. We will definitely take it into account in our next development plans.

Precisely we are working on a proposal for a next W3F grant that matches nicely with your questions.

The overall vision is to build an open-source system, that you can self-host or make use of a hosted version, for running and managing monitoring agents. We plan to have it integrated with standard platforms like Prometheus and Grafana for time series of events of interest and alerting. We also have the plans for an open marketplace for monitoring programs and data which could be a decentralised network.

Here we have a PDF of some mock-ups of the monitoring portal:

We would appreciate any feedback or suggestions that you may have!

1 Like
4

BTW, with regards to your write-up on a Polkadot native DApp for monitoring, we are super keen to build our monitoring service decentralised and have been thinking about how this could be done. We’ve checked how Forta works and they rely on “centralised” components to monitor the SLA of the bots. We envision a similar solution, but we’re still exploring how it could be made more decentralised while preserving the uptime and reliability of the agents. If you know of some project that we can get inspiration from, or if you have some ideas we would love to hear about them!

1 Like
5

You can add app.subrelay.com

6

Thank you @rich :grin:

We want to point out some differences:

  • Our SDK is not limited to just relaying events. You can express complex monitoring logic for events, extrinsics, states, smart contract calls and mix it up with other capabilities like creating account graphs, following addresses etc. There are some examples in the repo.
  • The agents will bundle vertical business logic ready to be used, e.g. anomaly detection over extracted events of interest. Note that these events are not just onchain events but curated or extracted data points (we call it events of interest). Think of it as complex events processing. Ref Complex event processing - Wikipedia
  • Our primary focus will be on providing logic for security and compliance
  • We separate the data from the alerting, akin to Prometheus. This will allow us to offer interesting curated data sets.
  • We aim to make it easy to integrate with existing monitoring and incident response systems
  • Adding actuator to the agents is something that we have in mind, but we want to first tackle the sensing part
1 Like