Reputation scoring over 64 million wallets

Backend, data and infrastructure work on Octan Network’s on-chain reputation scoring, where indexing went from hours to minutes. What I can say about it, and how sure I am.

From September 2022 to January 2025 I worked at Octan Network as a blockchain developer, building backend services and internal tools in Go and TypeScript. The project I’m writing about here is reputation scoring: ranking on-chain wallets and serving analytics about them.

The project’s repository is public: Octan-Labs/Reputation-scoring.

My part

I didn’t own all of Octan, and this isn’t a “I built everything” post. On this project my scope was:

database design;
backend APIs;
the ClickHouse analytical workloads;
deployment, on Kubernetes and AWS;
performance optimisation.

The data stack combined TimescaleDB and ClickHouse.

The scale

Production data processing scanned approximately 64 million wallets. That’s the total number of wallets scanned. It isn’t a count of users or customers, or of wallets indexed at any one moment. Blockchain numbers get inflated easily, so I want to be precise about what this one means.

Why ClickHouse

Reputation scoring is mostly aggregation and ranking: summarise a lot of activity per wallet, then order wallets against each other. Those are analytical workloads, and ClickHouse fits them well. There was also pressure on infrastructure cost, and ClickHouse helped there too. I’m keeping that benefit qualitative because I don’t have a cost figure I can stand behind.

The results

After the optimisation work, roughly:

indexing went from hours to minutes;
search went from minutes to under five seconds.

These were production observations, not a controlled benchmark. I no longer have the logs or screenshots, so I give them as approximate first-person results and nothing more precise. If I quoted “a 37× speed-up” you’d be right to ask where the number came from, and I wouldn’t have an answer.

What I took from it

When one workload is mostly aggregation and ranking, give it a store built for that, rather than stretching the transactional or search side to cover it. I applied the same thinking later on a B2B search platform: Elasticsearch for search, ClickHouse for analytics.

The general rule, and when not to follow it, is in A second datastore has to earn its operating cost.