Thor - Vechain Ecosystem

1. Introduction

VeChain Foundation engaged Halborn to conduct a security assessment of the VeChainThor Go codebase beginning on September 5, 2025 and ending on October 31, 2025. The security assessment was scoped to consensus, staking, networking, API, and runtime components in the GitHub repository provided to the Halborn team.

2. Assessment summary

A senior Halborn security engineer performed a full manual review of the Go codebase with targeted automation. The objectives were to:

• Ensure protocol components operate as intended under adversarial conditions.

• Identify logic, state-transition, and concurrency risks.

• Recommend robust, low-risk remediations aligned with production constraints.

Key risk themes included:

• Unsigned arithmetic underflows in staking and epoch housekeeping could block expected activations or corrupt state.

• Scheduler policy allows offline proposers to be included and auto-reactivated, weakening uptime enforcement.

• Panic usage in consensus flow reduces fault tolerance and can crash nodes under rare invariants.

• Input validation gaps (e.g., zero weights) reduce robustness and future maintainability.

3. Key recommendations

• Harden arithmetic in staking/housekeeping: Guard decrements and bounds checks to prevent unsigned underflow when the leader set is empty and an exit is scheduled; validate subtraction does not underflow queued stake.

• Enforce proposer liveness policy: Exclude offline validators from scheduling and remove auto-activation side-effects; ensure updates cannot clear OfflineBlock implicitly.

• Replace panics in consensus-critical paths: Return typed errors instead of panics in scheduling/consensus to prevent node crashes and enable graceful rejection/recovery.

• Validate scheduler inputs: Require weight > 0 before computing scores to avoid undefined behavior and simplify invariants.

• Strengthen state-transition prechecks: Centralize and reuse validation guards for staking transitions to ensure consistent behavior across services and edge epochs.

4. Test approach and methodology

• Architecture and threat modeling: Reviewed consensus, staking, scheduling, activation/exit flows, and state persistence boundaries.

• Manual code review: Deep review of consensus, scheduler, staking services, epoch housekeeping, and API boundaries for logic and state-transition flaws.

• Static analysis and linters: Ran Go-focused checks (e.g., go vet, staticcheck, golangci-lint) to flag common correctness and robustness issues.

• Targeted dynamic validation: Reproduced edge scenarios described in findings; leveraged existing fuzz and property tests around blocks and state transitions where present; recommended additional unit/property tests for activation/exit edge cases.

• Defense-in-depth recommendations: Proposed invariant checks, error handling upgrades, and precondition guards to improve resilience and maintainability.