Veilon Info
A zk-native cross-chain wallet and protocol for private, untraceable transfers, swaps, and bridging powered by stealth addresses & encrypted transaction layers.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Security Assessments
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Contract cannot be locked
Owner cannot lock any user funds.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is renounced
The contract does not include owner functions that allow post-deployment modifications.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Backend (Relayer) Analysis Statement
Service Analysis
The Veilon Relayer is a Node.js / Express service that supports a zk-SNARK privacy pool by verifying client-generated Groth16 proofs, maintaining a depth-20 Poseidon incremental Merkle tree, tracking spent nullifiers, and providing an ECDH-encrypted transport channel for sensitive request/response payloads. Across four audit cycles the architecture has matured substantially: the relayer no longer generates proofs, no longer sees user secrets, and no longer leaks internal error details. The remaining concerns are concentrated in operational durability and defense-in-depth around the encryption layer rather than in the core cryptographic flow:
- State durability — the Merkle tree, root history, and nullifier set are held entirely in-memory; a restart erases all of them. The on-chain contract still enforces the canonical invariants, so fund safety is not at risk, but valid proofs may be rejected and `/merkle-path` becomes unusable until the operator rebuilds state.
- No on-chain synchronisation — the backend tree is an independent source of truth rather than a cache of contract events. Direct on-chain submissions (bypassing the relayer) silently desynchronise it.
- ECDH transport hardening — encryption is optional via a request flag, the cached AES session keys never expire, and CryptoJS is invoked in passphrase / CBC mode rather than with a parsed key and AEAD. The new persistent ECDH wallet (`RELAYER_ECDH_PRIVATE_KEY`) is initialised lazily, so a misconfigured production deployment starts cleanly and silently falls back to the unencrypted code path.
- TOCTOU race in nullifier checks — `isNullifierUsed` runs before, and `addNullifier` after, an awaited proof verification, allowing concurrent requests with the same nullifier to both succeed at the relayer (the contract still rejects the second on-chain).
- Cross-chain replay — the new `chainId` allowlist (`L6` in source) is a useful soft policy at the API boundary, but it is bypassable (missing chainId is treated as valid, mainnet and testnets share one allowlist) and the chainId is still not bound into the proof's public inputs. This remains a circuit-level concern.
Operator Privileges & Trust Model
The relayer is a privileged-but-narrowed component in the Veilon trust model. Following the re-architecture, the operator retains the following capabilities and constraints:
- Issues and rotates Bearer-token API keys (`API_KEYS` env var) that gate every privacy endpoint.
- Holds the persistent ECDH private key (`RELAYER_ECDH_PRIVATE_KEY`) whose public counterpart is pinned client-side; rotation requires a coordinated mobile-app update.
- Configures the chainId allowlist (`ALLOWED_CHAIN_IDS`) and the CORS origin allowlist (`ALLOWED_ORIGINS`).
- Controls the Merkle tree process — restarting the service clears the local tree, root history, and nullifier set.
- The operator cannot see user secrets, nullifier preimages, or randomness — these never leave the client device.
- The operator cannot forge a proof — proof verification uses the canonical verification keys in `circuits/keys/` and the smart contract independently re-verifies on-chain.
- The operator cannot bypass on-chain double-spend prevention — the contract maintains its own nullifier set and rejects duplicates regardless of relayer behaviour.
- The operator cannot mint, freeze, or move user funds — the relayer holds no signing key for the privacy pool contract; it is a verifier and indexer only.
Security Features
The codebase implements several positive security controls that have been verified across the re-audit cycle:
- API key authentication with `crypto.timingSafeEqual` constant-time comparison and a hard production check that refuses to start without configured keys.
- Two-tier rate limiting (100 req/min global, 20 req/min on `/api/privacy/*`) plus `helmet` and a configurable CORS policy.
- Three-layer production guard against mock proofs: `validateCircuitFiles()` fails startup if any artifact is missing, `generateMockProof()` throws in production, and `verifyProof()` throws (rather than silently returning `true`) when a verification key is absent.
- Client-side proof generation enforced by `isProduction()` throws on every `generate*Proof` method — no secret material ever reaches the relayer in production.
- Generic error responses across all seven catch blocks; only `error.message` is logged server-side, never returned to the client.
- Persistent server-side ECDH wallet driven by `RELAYER_ECDH_PRIVATE_KEY`, exposing a `/api/privacy/public-key` endpoint that returns both the compressed key and its `keccak256` hash for client-side pinning.
- Depth-20 Poseidon incremental Merkle tree with a 30-slot ring buffer of recent roots, enabling tolerance for slightly stale client proofs.
Auditor's Closing Remarks
The Veilon backend has progressed from an architecture where the relayer was effectively a single-point-of-failure for privacy (it saw every secret, generated every proof, and had no Merkle tree at all) to one where its role is correctly narrowed to verifier and state cache. All eight findings classified Medium or higher in the original audit (3 Critical, 3 High, 1 Medium, 1 Low) are now resolved and have been re-verified across four cycles. The remaining work is no longer about privacy or fund safety — those are anchored in the smart contract — but about operational robustness: state persistence, on-chain event indexing, removing the encryption-optional fall-through, fail-fast validation of `RELAYER_ECDH_PRIVATE_KEY` at startup, and closing the nullifier TOCTOU window. The new chainId allowlist and persistent ECDH wallet are welcome hardenings, but neither replaces the underlying primitive (chain binding belongs in the circuit; encryption should be mandatory once a handshake has occurred). Documentation drift is the most visible remaining hygiene issue: `README.md` still describes the pre-refactor architecture, including secret-bearing responses and server-side proof generation, and should be rewritten to match the current implementation before any external integrator reads it.
Note — This audit report consists of a security analysis of the Veilon Relayer Service backend codebase (`backend-main`). The analysis is read-only static review, performed across four cycles between 2026-02-24 and 2026-04-30, and is cross-referenced with the Veilon smart contract audit and the Veilon mobile audit where applicable. We did not audit the deployment infrastructure (Railway.app configuration, secrets management, network topology), the trusted-setup ceremony that produced the `*_final.zkey` files, or any third-party service the relayer may depend on at runtime. Operators and integrators should treat the on-chain contract as the canonical security boundary; the relayer's checks are pre-validation and convenience, not authority. We recommend reviewers conduct their own assessment of the deployment environment before relying on this service in production.
Files and details
Findings and Audit result
critical Issues | 3 findings
Resolved
#1 critical Issue
Trust Model Violation / Secret Exposure to Relayer
The backend relayer receives commitment secrets (secret, nullifier, randomness) in plaintext via HTTP POST from the mobile app. The relayer sees all private values needed to reconstruct commitments, generate nullifier hashes, and forge proofs. This completely negates the privacy guarantees of ZK proofs: the relayer can link deposits to withdrawals, reconstruct user balances, and impersonate users. In a genuine privacy protocol, proof generation MUST happen client-side so that secret values never leave the user's device. The relayer architecture makes the entire ZK layer security theater — it proves nothing to a party that already knows all the secrets.
Resolved
#2 critical Issue
Mock Proof Bypass in Production Path
When compiled circuit files (.wasm, .zkey) are not present, the proof generator falls back to generating random mock proofs that are cryptographically meaningless. There is NO runtime flag, environment check, or guard to prevent this in production. The mock proofs have random pi_a, pi_b, pi_c values that will never pass on-chain Groth16 verification. Furthermore, the verifyProof() method (line 585-587) returns true when the verification key file is missing, silently bypassing verification. If the production backend is deployed without circuit files (which appears to be the current state based on the README), all proof generation is fake.
Resolved
#3 critical Issue
No Merkle Tree — Fundamentally Broken Privacy Model
There is NO Merkle tree implementation in the backend. The backend has zero Merkle tree code — no tree construction, no path computation, no root tracking. The ZK circuit inputs do not include Merkle path or root. Without a Merkle tree: (1) There is no anonymous set — every commitment is individually identifiable. (2) Unshield/transfer operations directly reference the input commitment in calldata, making all transaction flows fully traceable on-chain. (3) The entire privacy model is broken because an observer can trivially link shield → unshield → transfer chains.
high Issues | 3 findings
Resolved
#1 high Issue
No Authentication / No Rate Limiting
All backend API endpoints are completely unauthenticated and have no rate limiting. Anyone who discovers the relayer URL can: (1) generate unlimited proofs, consuming server CPU, (2) submit malformed requests to probe for vulnerabilities, (3) perform denial-of-service by flooding proof generation (which is computationally expensive). The CORS policy is permissive (allows all origins). The production URL (https://veilonbackend-production.up.railway.app) is exposed in the mobile source code.
Resolved
#2 high Issue
Secrets Returned in API Responses
The shield endpoint returns secret, nullifier, and randomness in the HTTP response body. The unshield and transfer endpoints return changeSecret, changeNullifier, and changeRandomness. These values are the private witness for ZK proofs. Transmitting them over the network (even over HTTPS) creates multiple attack vectors: network logging, proxy inspection, CDN caching, server access logs, and client-side caching.
Resolved
#3 high Issue
Sensitive Data in Server Logs
The backend logs truncated (but still partially revealing) secret values, nullifiers, and randomness to console.log. The routes log all incoming request parameters including amounts, recipients, and chain IDs. In production, these logs may be persisted to log aggregation services (CloudWatch, Datadog, etc.), creating a permanent record of all private transaction details.
medium Issues | 1 findings
Resolved
#1 medium Issue
Floating Point Arithmetic for Financial Calculations
Change amount calculation uses parseFloat subtraction: (parseFloat(inputAmount) - parseFloat(outputAmount)).toString(). Floating point arithmetic can produce precision errors (e.g., 0.1 + 0.2 !== 0.3). These imprecise values are then passed to ethers.parseEther() which expects exact decimal strings. This could cause amount mismatches that fail on-chain validation (outputAmount + changeAmount != inputAmount).
low Issues | 1 findings
Resolved
#1 low Issue
Error Messages Expose Internal Details
The global error handler returns err.message to the client, which may contain stack traces, file paths, or internal error details that aid attackers in reconnaissance.
informational Issues | 8 findings
Pending
#1 informational Issue
No Test Coverage
The backend codebase contains zero test files. There are no unit tests for proof generation, no integration tests for the proof → contract flow, and no tests for input validation or error handling.
Pending
#2 informational Issue
No Monitoring, Alerting, or Observability
There is no application monitoring, error reporting (Sentry, etc.), performance tracking, or health alerting. Console.log is the only logging mechanism. For a financial application handling real value, this is insufficient.
Pending
#3 informational Issue
Unpinned Dependencies
All dependencies use caret (^) versioning, allowing minor/patch updates that could introduce breaking changes or vulnerabilities. For a security-critical application, versions should be pinned.
Pending
#4 informational Issue
Health Endpoint Leaks Configuration Details
The privacy health endpoint returns internal state including leafCount, nullifierCount, and the current Merkle root. While these are not secrets, they reveal system load and usage patterns.
Pending
#5 informational Issue
Public Signal Ordering Not Enforced
The ordering of public signals is critical for proof verification but is only documented in code comments and not enforced programmatically. No shared schema or constant mapping exists for public signal indices.
Pending
#6 informational Issue
Insufficient Input Validation
Input validation is minimal: (1) amount validation uses parseFloat which accepts strings like '1e18', 'Infinity', 'NaN'. (2) recipient address is not validated — no checksum, no format check, no zero-address check. (3) No maximum amount check. (4) No schema validation library used.
Pending
#7 informational Issue
TypeScript Strict Mode Disabled
The TypeScript configuration has strict: false, noImplicitAny: false, and noImplicitReturns: false. This allows type-unsafe code, implicit any types, and missing return statements — all of which can introduce subtle runtime bugs in a security-critical application.
Acknowledged
#8 informational Issue
Cross-Chain Replay Attack — No Chain Binding in Proofs
ZK proofs do not include block.chainid, contract address, or any chain-specific identifier in the public inputs. A proof generated for one chain could theoretically be submitted on another chain where the same contracts are deployed with the same commitment.