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
Top comments (1)
Next milestone: Creator Wallet Analysis (v0.5)