VerifAI

Web3 projects expose useful trust signals across many different places: smart contracts, source-code repositories, websites, DNS records, domains, certificates, and public reputation sources. Looking at only one source can give an incomplete picture.

Web3 users often have to make trust decisions from incomplete or disconnected information. Another problem is relying too heavily on AI-generated conclusions that may sound confident without having enough evidence behind them.

The approach separates facts, scoring, and interpretation. Evidence collectors gather technical signals, a rule-based engine determines the authoritative assessment, and AI adds context without being allowed to change the score or invent missing evidence.

This evidence-first boundary is part of the implemented architecture.

User submits a project
Collectors gather technical evidence
Evidence is normalized into a consistent structure
The scoring engine evaluates the evidence
AI explains important findings and uncertainty
A structured report is generated
The report is hashed
The hash is anchored to Hedera
The report can later be checked for tampering

The application is built as a TypeScript Nx monorepo with a Next.js frontend and NestJS backend and worker services. PostgreSQL stores application and assessment data, while Redis and BullMQ manage background processing. The production stack is containerized with Docker and deployed behind Nginx on Oracle Cloud Infrastructure.

I implemented the platform as separate web, API, worker, database, cache, and supporting infrastructure components. Long-running evidence collection and analysis jobs are processed in the background rather than blocking normal web requests, while reports and evidence remain stored for later review and verification.

The repository documents Next.js, NestJS, PostgreSQL, Redis, BullMQ, Docker, Nginx, OCI and Hedera as core parts of the system.

Security was treated as part of the architecture rather than an extra feature. The platform includes SSRF protection for external collection, secure wallet authentication, JWT-based sessions, HttpOnly refresh cookies, Argon2 hashing, role-based access control, restricted cloud networking, HTTPS, protected secrets, non-root containers, and validated object uploads.

The security design focuses on limiting what users, services, and external inputs are allowed to do. Databases and internal services are not intended for direct public exposure, external collection is validated, authentication is server-controlled, and AI cannot override verified evidence or deterministic risk scoring.

These controls are documented in the public security showcase and current implementation status.

One of the hardest parts was handling evidence that is incomplete, unavailable, or contradictory. The system needed to distinguish between something being confirmed, not observed, or simply unknown instead of treating missing data as a security failure.

Another challenge was keeping AI useful without making it authoritative. I had to design clear boundaries so AI could explain evidence and risk context while deterministic code remained responsible for factual assessment and scoring.

Security analysis becomes more useful when every finding can be traced back to evidence. I also learned that an explicit “unknown” is often more trustworthy than forcing a positive or negative conclusion when the available evidence is incomplete.

Building VerifAI reinforced the importance of separating deterministic security decisions from AI interpretation. AI can help explain complex evidence, but important security conclusions still need clear rules, provenance, validation, and predictable failure behaviour.

Continue production verification, strengthen independent security testing, expand supported evidence sources, improve monitoring and operational visibility, and move Hedera integration toward mainnet only after the required security and production checks are complete.

The next improvements will focus more on production maturity than simply adding features: deeper security testing, stronger monitoring, additional evidence sources, improved external-intelligence coverage, and further validation before any mainnet use.

The current project status specifically records mainnet as not yet approved, so I would not describe VerifAI as a finished mainnet product on the portfolio.