Building a Solana Risk Engine: From Mock Data to Mainnet

VeritasLab — Wed, 03 Jun 2026 23:14:27 +0000

When I started building NexusVeritas, I made a mistake that many developers make.

I spent far too much time on architecture, specifications, documentation, threat models, and future plans.

The project looked impressive on paper.

The codebase, however, barely existed.

At some point I realized that documentation was no longer the bottleneck. The next milestone wasn't another design document—it was proving that the core engine could actually work.

Lessons learned while building NexusVeritas, a Solana-first token risk intelligence platform.

The Goal

NexusVeritas is a Solana-first token risk intelligence platform.

The idea is simple:

Given a token address, return a deterministic risk score based on observable on-chain signals.

No hype.

No sentiment analysis.

No AI-generated confidence scores.

Just measurable facts.

The API response looks like this:

{
  "score": 40,
  "class": "MEDIUM",
  "reasons": [
    "Mint authority enabled",
    "Freeze authority enabled"
  ]
}

Version 0.1 — Mock Everything

The first version was intentionally simple.

The architecture consisted of:

Token Address

↓

Mock Snapshot

↓

Risk Engine

↓

REST API

The risk engine already supported:

Mint authority analysis
Freeze authority analysis
Holder concentration checks
Risk classes (LOW → CRITICAL)
Explainable reasons

At this stage the API worked, but every token was evaluated using mock data.

Useful for testing.

Useless for real users.

Version 0.2 — Connecting to Solana Mainnet

The first real milestone was integrating Solana RPC.

I chose Helius because setup was straightforward and the developer experience was excellent.

The goal was to fetch actual token metadata instead of simulated values.

The adapter began collecting:

Mint authority status
Freeze authority status
Largest token holders
Supply information

For the first time, the engine was evaluating real tokens on Solana mainnet.

That changed everything.

Holder Concentration Analysis

One of the earliest useful signals was holder concentration.

Using getTokenLargestAccounts, the engine calculates how much of the supply is controlled by the largest holders.

Example results:

Token	Top Holder Concentration
USDC	~0%
BONK	~0%
WIF	~44%
PYTH	~52%
New Pump.fun Tokens	10–40%

This immediately revealed an important lesson.

A high concentration isn't automatically malicious.

Context matters.

Some legitimate projects naturally have concentrated ownership during early growth stages.

Because of this, I set the threshold conservatively.

The goal is reducing false positives, not maximizing alerts.

Version 0.3 — Token Age Analysis

The next feature seemed easy.

Estimate token age.

In reality, it exposed one of the first interesting engineering problems.

The naive approach was:

Query token signatures.
Find the earliest transaction.
Calculate age.

It worked perfectly for small tokens.

Then I tested USDC.

The result claimed that USDC was only a few minutes old.

Clearly impossible.

The reason was simple:

Large tokens have enormous transaction histories.

Even requesting hundreds or thousands of signatures doesn't reach the creation event.

The solution wasn't perfect age detection.

The solution was reliability detection.

The engine now marks age calculations as either:

Reliable
Unreliable

If confidence is low, age-based penalties are ignored.

When uncertain, don't guess.

Security Hardening

As soon as the API became public-facing, infrastructure concerns appeared.

The focus shifted toward:

Input validation
Fail-safe defaults
Error handling
Rate limiting
Confidence reporting

One principle guided every decision:

Security tools should fail safely.

If data quality is uncertain, the engine should communicate uncertainty instead of pretending to know the answer.

What Actually Matters

One lesson became obvious during development.

The browser extension is not the product.

The dashboard is not the product.

Even the API is not the product.

The product is the risk engine.

Everything else is simply a way to access it.

That realization helped prioritize development:

Risk Engine
Solana Adapter
API
Extension

Not the other way around.

Current State

Today NexusVeritas includes:

Working Solana RPC integration
Deterministic risk scoring
Holder concentration analysis
Token age analysis
Confidence validation
Public REST API

The architecture is designed for future multichain expansion, but the current focus remains Solana.

What's Next

The next milestone is creator wallet analysis.

Instead of focusing only on a token, the engine will evaluate the behavior of the wallet that created it.

Questions like these become possible:

Has this wallet launched multiple tokens?
Were previous launches abandoned?
Is there a pattern of suspicious deployments?

That moves the system one step closer to behavioral security analysis rather than static token inspection.

And that's where things start getting interesting.

Links

GitHub:
https://github.com/cryptaveritas/nexusveritas-api

Follow development updates:
https://x.com/Runecipher137

DEV Community: VeritasLab