VerifiedX-Core - VerifiedX


Prepared by:

Halborn Logo

HALBORN

Last Updated 02/27/2026

Date of Engagement: January 19th, 2026 - February 20th, 2026

Summary

100% of all REPORTED Findings have been addressed

All findings

23

Critical

6

High

5

Medium

10

Low

2

Informational

0


1. Introduction

VerifiedX engaged Halborn to conduct a security assessment on their vBTC V2 system from January 19th, 2026 to February 20th, 2026. The security assessment scope was limited to the system components provided to Halborn. Commit hashes and further details can be found in the Scope section of this report.


VerifiedX vBTC V2 is a tokenized Bitcoin system built on the VerifiedX (VFX) blockchain. It uses FROST threshold Schnorr signatures (via a Rust FFI library) to coordinate distributed key generation (DKG) for Taproot (P2TR) deposit addresses and to collectively sign Bitcoin withdrawals. The system integrates on-chain consensus/state transitions (VFX transactions and state tree updates) with Bitcoin coordination (validator discovery, MPC ceremony orchestration, ElectrumX-based Bitcoin network interactions).

2. Assessment Summary

Halborn was allocated 25 days for this engagement and assigned one full-time security engineer to conduct a comprehensive review of the system components within scope. The engineer(s) have expertise in blockchain protocol security, Bitcoin coordination security, and cryptographic integration, with advanced skills in penetration testing and exploitation of node-side APIs and MPC systems.


The objectives of this assessment were to:

    • Identify potential security vulnerabilities within the system.

    • Verify that the system functionality operates as intended.


In summary, Halborn identified several areas for improvement to reduce the likelihood and impact of risks, which were fully addressed by the VerifiedX team. The main recommendations were:

    • Implement and enforce end-to-end MPC correctness: ensure DKG yields valid Bech32m P2TR addresses derived from the group key, and ensure signing produces verifiable Schnorr witnesses over correct BIP341 sighashes (per-input as required), failing closed on any mismatch.

    • Ensure consensus/state coverage matches the protocol for all vBTC V2 transaction types, binding state transitions to consensus-validated transaction properties and preventing “no-op” or divergent behavior.

    • Harden validator/MPC networking surfaces (validator discovery, FROST endpoints, ElectrumX I/O) with strict input validation, bounded resource usage, timeouts, and clear operational runbooks to prevent liveness failures and abuse.

3. SCOPE

REPOSITORY
(a) Repository: VerifiedX-Core
(b) Assessed Commit ID: 7a2e38b
(c) Items in scope:
  • ReserveBlockCore/Controllers/ActionFilterController.cs
  • ReserveBlockCore/Bitcoin/Controllers/VBTCController.cs
  • ReserveBlockCore/Bitcoin/Services/VBTCService.cs
↓ Expand ↓
Out-of-Scope: Third party dependencies.
Remediation Commit ID:
Out-of-Scope: New features/implementations after the remediation commit IDs.

4. Findings Overview

Security analysisRisk levelRemediation
Incorrect block-level transaction parsing can make valid vBTC V2 validator lifecycle transactions unmineableCriticalSolved - 02/06/2026
A broken validator heartbeat check can cause the active validator set to decay to zero and break vBTC V2 livenessCriticalSolved - 02/06/2026
Inconsistent client–server API contracts can break FROST DKG and signing ceremonies and prevent core vBTC V2 flowsCriticalSolved - 02/15/2026
Non-deterministic validator service startup can prevent the FROST server from running and break vBTC V2 MPC livenessCriticalSolved - 02/18/2026
Incorrect Taproot signing semantics can produce invalid Bitcoin withdrawals and leave funds stuckCriticalSolved - 02/16/2026
Insufficient consensus validation of transfer data enables arbitrary vBTC V2 balance manipulationCriticalSolved - 01/29/2026
Missing sender binding in the vBTC V2 withdrawal lifecycle enables unauthorized state transitions and unbacked burnsHighSolved - 01/29/2026
Insufficient validation of validator network endpoints can enable SSRF and internal network targetingHighSolved - 02/06/2026
Insufficient validation of FROST protocol inputs can expose native FFI to crash and resource-exhaustion risksHighSolved - 02/15/2026
Weak DKG session authorization can enable ceremony sabotage and quorum manipulationHighSolved - 02/15/2026
Missing consensus support for withdrawal cancellation can leave funds stuck and prevent recovery governanceHighSolved - 02/16/2026
Incorrect replay-prevention keying can enable cross-user collisions and denial of serviceMediumSolved - 01/29/2026
Non-canonical address encodings can enable address aliasing and user-assisted fund lossMediumSolved - 02/06/2026
Missing state-transition handling can cause vBTC V2 transfers to burn fees without applying on-chain balance updatesMediumSolved - 02/13/2026
Missing consensus-state handling can cause vBTC V2 contract creation to succeed locally but have no on-chain effectMediumSolved - 02/16/2026
Ambiguous local contract records can bypass withdrawal authorization and enable unauthorized vBTC V2 withdrawalsMediumSolved - 01/29/2026
Placeholder MPC artifacts can break deposit address generation and withdrawal signing for vBTC V2MediumSolved - 02/24/2026
Hardcoded deposit address outputs can misdirect vBTC deposits and cause irreversible fund lossMediumSolved - 02/20/2026
Unrestricted FROST session creation can enable remote resource exhaustion and degrade MPC availabilityMediumSolved - 02/15/2026
vBTC v2 validator registration and exit flow blocked by zero fee requirement conflicting with global transaction validationMediumSolved - 01/29/2026
Insufficient trust and I/O hardening for ElectrumX can allow chain-data tampering and withdrawal disruptionMediumSolved - 02/16/2026
Withdrawal state machine can enter a terminal state that blocks future withdrawalsLowSolved - 01/29/2026
Inaccurate deployment documentation can cause misconfiguration and break vBTC V2 MPC livenessLowSolved - 02/18/2026

Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.

// Download the full report

VerifiedX-Core

* Use Google Chrome for best results

** Check "Background Graphics" in the print settings if needed