Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

Veilon Info

www.veilon.io

A zk-native cross-chain wallet and protocol for private, untraceable transfers, swaps, and bridging powered by stealth addresses & encrypted transaction layers.

Veilon Logo
Onboarded date 25/02/2026

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.

20.00
Poor Excellent

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

Select the audit
"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
N/A
Network N/A
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2026/02/25
Revision date 2026/02/25

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:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. 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.

No Audit Comments.

Files and details

Findings and Audit result

Critical
High
Medium
4
Low
Optimization
5
Informational
critical Issues | 3 findings

Resolved

#1 critical Issue
Trust Model Violation / Secret Exposure to Relayer
src/services/proof-generator.ts + src/routes/privacy.ts
Lprivacy.ts:125-193
L199-323
L329-450; proof-generator.ts:166-220
L225-328
L333-445
Description

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.

Comments

The architecture has been redesigned around client-side proof generation. The relayer endpoints now accept only pre-computed values: commitment, proof, publicSignals, nullifierHash, merkleRoot, and similar public data. No secret material (secret, nullifier, randomness) is received by any endpoint. All three proof generation methods in proof-generator.ts are gated with a production check that throws if invoked when NODE_ENV=production. The relayer's role is now limited to proof verification and Merkle tree state management, which is the correct trust model for a privacy protocol.

Resolved

#2 critical Issue
Mock Proof Bypass in Production Path
src/services/proof-generator.ts
L92-120
L126-161
L452-482
Description

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.

Comments

Three layers of production safeguards are now in place. First, validateCircuitFiles() is called at startup and throws a fatal error if any circuit file is missing in production, preventing the server from starting. Second, generateMockProof() contains an explicit production guard that throws immediately. Third, verifyProof() now throws when the verification key is absent in production rather than silently returning true. In development mode, mock proofs and soft verification are still allowed, which is acceptable for local testing.

Resolved

#3 critical Issue
No Merkle Tree — Fundamentally Broken Privacy Model
src/services/merkle-tree.ts + src/routes/privacy.ts
Lmerkle-tree.ts:1-175; privacy.ts:174
L260-303
L380-426
L456-482
Description

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.

Comments

A Poseidon-based incremental Merkle tree (depth 20) has been implemented in src/services/merkle-tree.ts. It supports O(depth) insertions, maintains a ring buffer of 30 recent roots for stale-proof tolerance, tracks spent nullifiers, and computes Merkle paths for client-side proof generation. The privacy routes now integrate with it correctly: shield inserts leaves, unshield/transfer validate roots, check nullifiers, and insert change commitments. The fundamental absence of a Merkle tree is resolved. Remaining concerns around in-memory-only storage and lack of on-chain synchronisation are tracked separately as new findings.

Alleviation

Partially. The core data structure is implemented, but persistence and on-chain synchronisation are absent — see BE-NEW-01 and BE-NEW-03.

high Issues | 3 findings

Resolved

#1 high Issue
No Authentication / No Rate Limiting
src/server.ts + src/routes/privacy.ts
Lserver.ts:20-51
L62-98
L110; privacy.ts:all endpoints
Description

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.

Comments

API key authentication is now implemented via a Bearer token middleware with constant-time comparison to prevent timing attacks. The server refuses to start in production if no API_KEYS are configured. Two rate limiters are applied: a global limit of 100 requests per minute per IP, and a stricter 20 requests per minute limit on privacy endpoints. CORS is configurable via the ALLOWED_ORIGINS environment variable, with allowed headers restricted to Content-Type and Authorization. One minor gap remains: if ALLOWED_ORIGINS is not explicitly set in production, CORS defaults to allow-all rather than failing closed.

Resolved

#2 high Issue
Secrets Returned in API Responses
src/routes/privacy.ts
L176-180
L306-310
L428-436
Description

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.

Comments

No secret material is present in any API response. The shield endpoint returns only leafIndex and merkleRoot. Unshield returns newMerkleRoot and an optional changeLeafIndex. Transfer returns outputLeafIndex, changeLeafIndex, and newMerkleRoot. All secret generation and management now occurs client-side. Responses are additionally wrapped in ECDH-derived AES encryption when the client has performed a handshake.

Resolved

#3 high Issue
Sensitive Data in Server Logs
src/services/proof-generator.ts + src/routes/privacy.ts
Lprivacy.ts:182
L311
L438; proof-generator.ts:all; merkle-tree.ts:28
L47
Description

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.

Comments

All logging of secret values, request parameters, and commitment details has been removed. The remaining console.error calls in route handlers log only the error message string, not request bodies or cryptographic material. The Merkle tree initialisation logs a truncated root hash, which is public data. The codebase still uses console.log/console.error rather than a structured logging library, which is tracked under BE-INFO-02.

medium Issues | 1 findings

Resolved

#1 medium Issue
Floating Point Arithmetic for Financial Calculations
src/routes/privacy.ts
LN/A
Description

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).

Comments

The backend no longer performs any amount arithmetic. Change amount calculation is now the responsibility of the client. The routes validate that the amount field is present and positive, but do not perform subtraction or conversion. The parseFloat-based arithmetic pattern has been entirely removed.

low Issues | 4 findings

Pending

#1 low Issue
Error Messages Expose Internal Details
src/routes/privacy.ts
L114
L183-191
L313-321
L440-448
L477-480
L501-505
Description

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.

Comments

The global error handler in server.ts has been corrected and returns a generic message. However, all six route-level catch blocks in privacy.ts still return error.message directly to the client. This can expose internal details such as library error strings, file system paths, or database connection information depending on the failure mode. Each route handler should return its own generic fallback message and log the detailed error server-side.

Alleviation

The global error handler in server.ts now returns a generic 'Internal server error' message, which is correct.

Pending

#2 low Issue
Insufficient Input Validation
src/routes/privacy.ts
L151
L251
L131-158
L205-258
Description

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.

Comments

Amount validation still relies on parseFloat, which accepts edge-case values such as 'Infinity' and scientific notation. No schema validation library is in use. The recipient field is checked for presence but not for Ethereum address format or checksum. Since the backend now only relays pre-generated proofs and does not perform financial calculations itself, the practical risk is limited to wasted gas on transactions that will fail on-chain.

Alleviation

The zero-address default for recipient has been removed, and the endpoint now requires an explicit recipient. The floating-point arithmetic for change calculations is gone since the backend no longer computes amounts.

Pending

#3 low Issue
TypeScript Strict Mode Disabled
tsconfig.json
L8
L17-27
Description

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.

Comments

No change from the initial audit. strict remains false, and all permissive flags remain in their relaxed state. While not a direct vulnerability, this weakens confidence in type correctness across the service.

Pending

#4 low Issue
Cross-Chain Replay Attack — No Chain Binding in Proofs
multiple
Lproof-generator.ts:188-194
L286-293
L394-406
Description

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.

Comments

No change to the circuit inputs. Since proof generation has moved client-side, the backend has no mechanism to inject chain-binding data into proofs. This is now exclusively a circuit and client-side concern.

informational Issues | 5 findings

Pending

#1 informational Issue
No Test Coverage
N/A
LN/A
Description

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.

Comments

No test files have been added. The codebase still has zero test coverage.

Pending

#2 informational Issue
No Monitoring, Alerting, or Observability
N/A
LN/A
Description

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.

Comments

No structured logging, monitoring, or alerting has been added. All output still goes through console.log and console.error.

Pending

#3 informational Issue
Unpinned Dependencies
package.json
L11-32
Description

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.

Comments

No change. All dependencies still use caret versioning.

Pending

#4 informational Issue
Health Endpoint Leaks Configuration Details
src/routes/privacy.ts
L488-507
Description

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.

Comments

The privacy health endpoint is no longer publicly accessible. The information it returns (leaf count, nullifier count, root) is operational metadata available to authenticated callers only. The Merkle root is public on-chain data. The residual concern is that usage patterns are visible to any holder of a valid API key, which may not be desirable in a multi-tenant context.

Alleviation

The main /health endpoint in server.ts now returns only status, service name, and timestamp. The privacy health endpoint is behind authentication and rate limiting.

Pending

#5 informational Issue
Public Signal Ordering Not Enforced
src/services/proof-generator.ts
L188-194
L286-293
L394-406
Description

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.

Comments

No shared schema exists. Since the backend now only verifies proofs in production via snarkjs, which matches signals against the verification key internally, there is no production risk from signal ordering on the backend side. The concern remains relevant as a cross-system best practice between the client, circuits, and contract.

Alleviation

Impact is reduced because the backend no longer generates proofs in production. The ordering concern now applies only to development mock proofs.