Public blockchains make transactions visible.
They do not automatically answer a much more useful product question:
Can we trust the wallet behind those transactions?
I am the founder and CTO of Pharos Production - software development company. Since 2021, our team has worked with Ludo to build and scale the platform's blockchain indexing, real-time data processing, smart contracts, backend infrastructure and external APIs.
A wallet may have years of activity across several networks. That history can include transfers, smart contract calls and interactions with hundreds of protocols. The data is public, but turning it into a current and usable trust signal is a separate engineering problem.
And that is the problem behind Ludo - Reputation platform of Web3
Ludo is a live cross-chain reputation platform that converts onchain behavior into reputation data that users and other Web3 products can consume.
This article covers the architecture we can discuss publicly, the constraints that shaped it and the engineering lessons we took from the project.
The production requirements
This was not a prototype built around a small sample of wallets.
The platform needed to operate across more than 15 blockchain networks while supporting a growing number of users and external integrations.
The production targets included:
- More than 2 million scored wallet addresses
- More than 10,000 blockchain events processed per second
- API response times below 200 milliseconds
- 99.9% platform uptime
- More than 50 partner integrations
- Real-time reputation updates
The system also needed to support additional networks without requiring a redesign of the entire processing pipeline.
Those requirements immediately ruled out an architecture based only on scheduled batch jobs or heavy calculations inside the API request path.
Reputation is a streaming data problem
A reputation score is useful only while it reflects the current state of a wallet.
Suppose a score is recalculated once every 24 hours. A wallet can change its behavior shortly after the calculation, while connected products continue making decisions with stale information.
Calculating the complete score every time an API consumer requests it creates a different problem. The request path becomes responsible for reading and aggregating large amounts of historical data. Latency grows with the amount of activity associated with the wallet.
For Ludo, we treated reputation as a continuously updated data product.
Blockchain activity enters the system as a stream. New events are processed as they arrive and the relevant reputation state is updated before an external product requests it.
That keeps expensive event processing outside the latency-sensitive API path.
At a simplified level, the architecture looks like this:
Blockchain networks
|
v
Chain-specific indexing
|
v
Apache Kafka
|
v
Apache Flink
|
v
Reputation processing
|
+--------------------+
| |
v v
Apache Cassandra Apache Pinot
| |
+----------+---------+
|
v
Spring Boot API services
|
+----------+-----------+----------------+
| | |
v v v
Web platform Browser extension Partner APIs
|
v
External Web3 products
This is a public, simplified view. It intentionally leaves out proprietary scoring rules and internal data models.
Separating blockchain ingestion from reputation logic
Supporting more than 15 networks creates a problem that has little to do with the scoring formula itself.
Different chains expose different data structures, finality models and indexing behavior. Even similar actions can be represented differently from one network to another.
If every downstream service has to understand the native format of every blockchain, adding a new network becomes progressively more expensive. The scoring layer also becomes tightly coupled to chain-specific implementation details.
The architecture therefore needs a clear boundary between blockchain ingestion and reputation processing.
Chain-specific indexing is responsible for reading the network and translating relevant activity into a consistent internal representation. Downstream processing can then operate on normalized events instead of repeatedly interpreting raw chain data.
This separation helped our team deliver production-grade indexing for additional blockchain networks without rebuilding the rest of the platform each time.
The broader lesson is straightforward:
Normalize chain-specific behavior at the system boundary. Do not allow native blockchain formats to spread through the complete backend.
Kafka as the event backbone
Apache Kafka handles the continuous stream of blockchain activity.
Its role is larger than moving data between two services. Kafka provides a durable boundary between ingestion and processing.
Blockchain indexers can publish events without being directly coupled to every consumer. Processing services can evolve independently and additional consumers can be introduced without modifying the indexing layer.
This matters in a reputation platform because the same source activity may eventually support several workflows:
- Reputation state updates
- Historical analysis
- Product dashboards
- Audit and traceability
- New scoring models
Kafka also makes it possible to absorb short-term differences between the rate at which events arrive and the rate at which downstream services process them.
For this type of system, partitioning requires particular care. Events that update the same logical entity need predictable processing order while the workload still needs to be distributed across the cluster.
The exact partitioning model depends on the product's scoring rules, but the general requirement is consistent: ordering guarantees and horizontal scalability must be considered together.
Flink for incremental processing
Apache Flink processes blockchain events as they move through the system.
The important architectural decision was to update reputation state incrementally rather than repeatedly rebuilding it from the wallet's entire history.
When a relevant event arrives, the processing layer determines how that event affects the existing reputation state. The updated result can then be persisted for fast retrieval.
This approach provides two advantages.
First, the amount of processing required for a new event does not need to grow with the complete age of the wallet.
Second, the score can remain current without forcing API consumers to wait for historical aggregation.
Real-time processing also introduces operational questions:
- How should duplicate events be handled?
- What happens when events arrive late?
- How should a chain reorganization affect derived state?
- How can a calculation be replayed after scoring logic changes?
- Which state must remain auditable?
These questions cannot be solved by selecting a stream-processing framework alone. They need to be part of the data model and operating procedures from the beginning.
Using different storage systems for different workloads
A platform like Ludo does not have one universal database workload.
Operational reputation state, historical data and real-time analytical queries have different access patterns. Forcing all of them into one database would simplify the technology list while making the system harder to scale.
The public architecture uses several specialized components.
| Component | Primary role |
|---|---|
| Apache Cassandra | Scalable storage for user and reputation data |
| Apache Pinot | Low-latency real-time analytics and query workloads |
| Delta Lake | Organized historical data for analytics |
| Apache Kafka | Durable blockchain event streaming |
| Apache Flink | Stateful real-time event processing |
| Spring Boot | Backend services, APIs and reputation logic |
Cassandra supports distributed operational storage where the access patterns are known and horizontal scale matters.
Pinot serves analytical workloads that need fresh data and low query latency. This is useful for dashboards, curation tools and API consumers that need to filter or analyze reputation information.
Delta Lake retains organized historical data for deeper analysis and long-term processing.
This is a deliberate use of polyglot persistence. Each system has an explicit responsibility instead of becoming another item in the stack.
Keeping the API path fast
The platform needed to keep API response times below 200 milliseconds.
The main architectural principle behind that target was to avoid performing full reputation calculations during an external request.
By the time an API call arrives, the stream-processing layer has already processed relevant blockchain activity and updated the materialized reputation state.
The API layer can focus on controlled retrieval, authorization and response construction.
Spring Boot provides the backend foundation for these services. It also gives the platform a consistent way to expose reputation data to different consumers.
Those consumers include:
- The Ludo web platform
- A browser extension
- A Telegram Mini App
- Curator tools
- External Web3 products
- Mobile integrations
The platform also represents reputation through soulbound NFTs. Since these assets cannot be transferred or sold, the representation stays connected to the wallet activity that produced it.
The NFT is the verifiable product surface. The streaming and scoring infrastructure behind it is what keeps the representation current.
Integration is part of the product
It is easy to treat APIs and documentation as work that happens after the main platform is complete.
That approach would have limited Ludo's value.
A cross-chain reputation system becomes more useful when other products can place its trust signal inside their own workflows. That makes developer experience part of the architecture rather than a separate documentation task.
Pharos Production developed and documented APIs for external platforms. We also created SDKs and integration materials intended to reduce the amount of custom work required from each partner.
The result was a reduction of more than 60% in partner onboarding time.
More than 50 partners now use the platform across Web3 use cases including DeFi, gaming and social products.
The lesson applies beyond blockchain:
An infrastructure product is not complete when its internal services work. It is complete when another team can integrate it safely without depending on its original developers.
Infrastructure and reliability
The platform runs on AWS with Kubernetes and Istio.
Kubernetes provides the orchestration layer needed to deploy and scale independently evolving services. Istio handles service traffic management across the cluster.
Terraform supports repeatable infrastructure management while continuous load testing verifies that performance remains within the required range as the platform changes.
This operating model was designed around two practical requirements.
The first was traffic variability. Blockchain activity and partner demand do not always grow at a predictable rate.
The second was continuous expansion. Adding networks and integrations introduces new services, data flows and deployment requirements.
The infrastructure therefore needed to scale during traffic spikes without interrupting the products that rely on the reputation API.
The resulting platform maintains 99.9% uptime while processing more than 10,000 blockchain events per second without long queuing delays or data loss.
At this scale, uptime and latency are not only infrastructure metrics. They are part of the trust model.
A reputation signal is difficult to depend on when the API becomes unavailable during the exact periods when activity increases.
What Pharos Production delivered
Our work on Ludo covered more than one isolated service.
Pharos Production contributed to:
- Smart contracts deployed across multiple blockchain networks
- Cross-chain indexing and data aggregation
- Real-time event-processing infrastructure
- Reputation backend services
- Scalable server architecture
- Web and mobile integration APIs
- API documentation and SDKs
- Web, browser and Telegram product interfaces
- AWS and Kubernetes infrastructure
- Performance testing and production scaling
The project required blockchain engineering, backend architecture, data engineering and DevOps work to function as one delivery stream.
That combination is important.
A scoring model cannot become a reliable product without current source data. A data pipeline cannot create value without an accessible API. An API cannot become infrastructure for other businesses without predictable performance and operational reliability.
Production results
The current public project results are:
| Metric | Result |
|---|---|
| Supported blockchain networks | 15+ |
| Scored wallet addresses | 2M+ |
| Processing throughput | 10K+ events per second |
| API response time | Below 200 ms |
| Platform uptime | 99.9% |
| Partner integrations | 50+ |
| Reduction in partner onboarding time | More than 60% |
These figures are useful as proof of scale, but the more important result is architectural.
Ludo moved from a Web3 reputation concept to production infrastructure that other products can use inside live workflows.
Five lessons I would carry into another real-time Web3 platform
1. Start with the product decision
A reputation score has no meaning without the decision it is intended to support.
Before choosing a database or writing a scoring formula, define what another person or system will do with the result.
2. Make freshness an explicit requirement
"Real time" should not be a vague product claim.
Define how quickly a blockchain event must affect the result. That decision shapes ingestion, processing, storage and API design.
3. Isolate chain-specific complexity
Each new blockchain will introduce its own implementation details.
Keep those details at the indexing boundary and give downstream systems a stable internal event model.
4. Keep heavy computation outside the request path
An API with a strict latency target should retrieve prepared state rather than rebuild it from complete historical data.
Streaming and materialized state make that possible.
5. Design external integration from the beginning
Documentation, SDKs, versioning and predictable API behavior are core parts of an infrastructure product.
They should not be postponed until after the internal platform is considered finished.
Client perspective
Sergiu Draganus, co-founder and CEO of Ludo, has publicly confirmed that Pharos Production delivered the project's smart contracts, cross-chain data aggregation, scalable server infrastructure and documented integration APIs.
For teams carrying out technical vendor due diligence, Sergiu can provide a first-hand client reference about the collaboration and the process of building the platform with Pharos Production.
You can also review the complete Ludo case study with the project stack, results and client feedback.
Final thought
Public blockchain data does not create trust by itself.
It provides evidence.
The engineering challenge is to collect that evidence across networks, process it while it is still current and deliver it through infrastructure that other products can reliably use.
That is what our teams built with Ludo.
Where would you draw the boundary between a universal cross-chain reputation score and a score designed for one specific product?
Top comments (0)