# VEYLOCK internal audit report

2026-09-14 · Codex · Internal AI-assisted review

Not an independent audit or certification. Review complete; follow-up required.

28/28 local regression tests passed. No mainnet transactions were performed.

## VL-01 — Large account histories can hide the dashboard

Severity: Medium · Status: Open

src/app.js · refresh()

Evidence: Source inspection: refresh() throws once the collected schedule IDs reach 2,000, including exactly 2,000. Its catch handler clears every displayed row. Anyone can create a funded schedule naming an arbitrary recipient.

Impact: A sufficiently large history, including unsolicited schedules, can make the normal account dashboard unavailable. This does not change contract balances or recipient permissions. The public viewer can still read a known schedule ID.

Recommendation: Paginate the dashboard and retain already loaded rows. Show the remaining-page state instead of clearing the workspace. Add a 2,000-schedule boundary regression.

Validation: Confirmed from source; the full 2,000-transaction scenario was not executed.

## VL-02 — Extreme contract dates have an ambiguous display

Severity: Low · Status: Open

contracts/Veylock.sol · createSchedule(); src/app.js and src/public-vesting.js · date formatting

Evidence: A local transaction successfully created a schedule ending at uint64 max. The browser conversion rounded 18446744073709551615 to 18446744073709552000 and displayed “Invalid Date”.

Impact: Schedules created outside the normal date form can show unreadable dates. Conversion to Number also loses precision outside the safe integer range. No fund loss was reproduced; the local vesting amount probe matched the contract in this specific case.

Recommendation: Preserve uint64 timestamps as strings or BigInt and display exact Unix seconds when a date is outside the browser calendar range. Keep all financial time arithmetic exact.

Validation: Reproduced on a local Ganache EVM; see the evidence JSON.

## VL-03 — Creation receipt parsing does not check the emitter

Severity: Low · Status: Open

src/app.js · confirmCreate()

Evidence: The client chooses the first log that parses as ScheduleCreated. A synthetic log bearing a different emitter address was accepted by the same ABI parser.

Impact: A nonstandard token emitting an identically shaped event before the workspace event could misdirect the saved label or opened schedule ID. The real contract allocation and beneficiary are unaffected.

Recommendation: Filter receipt logs by the selected workspace address before parsing the event, and verify its creator, token and amount.

Validation: Parser behavior reproduced locally; a complete malicious-token browser transaction was not executed.

## VL-04 — Local Ganache dependency tree contains known advisories

Severity: High · tooling · Status: Open

package-lock.json · node_modules/ganache/node_modules/*

Evidence: npm audit --omit=dev reported 27 affected package entries: 4 critical, 17 high, 5 moderate and 1 low. Every reported node is nested under Ganache, which is declared as a devDependency.

Impact: These advisories concern the local test/build environment. Ganache is not imported by the browser entry points and is not copied into the Pages export. The command’s omit flag alone is therefore not a reliable production-exposure label for this installed tree.

Recommendation: Replace or isolate the outdated local EVM toolchain and re-run the advisory scan. Do not use this Ganache instance as a public RPC service.

Validation: Registry scan captured on September 14, 2026; paths checked against the application imports and export allowlist. No independent exploitability analysis of all 27 entries was performed.

## Coverage limits

- No independent external auditor or certification.
- No mainnet wallet transaction, deployed workspace address or live contract bytecode was validated by this review.
- No formal verification, coverage percentage, dedicated static-analysis engine, fuzzing campaign or comprehensive reentrancy test suite.
- The wallet-extension signing flow was inspected in source, not exercised end-to-end in a wallet-enabled browser.
- Third-party tokens, RPC/indexer operations, hosting-account security and all transitive dependency implementations are outside comprehensive coverage.
- This is a dated source snapshot, not continuous assurance of later releases.

See report.json for the exact source manifest and SHA-256 values.
