Testing Vector
L2 Performance on UTXO Rails
The HAL8 team, with the help of TxPipe, recently began structured testing of Vector, the UTXO-based L2 chain in the Apex Fusion ecosystem. Built as a tuned fork of Cardano, Vector is designed to deliver 4-second block times and high-throughput execution, all while preserving the advantages of the eUTXO model: parallel validation, statelessness, and native double-spend protection.
In this blog post, we’ll walk through the details of our current testing process: what we’re testing, how we’re testing it, and what early results look like. This is aimed at a technically experienced audience — especially those familiar with Cardano’s architecture and challenges.
The Goal: Fast Blocks
Vector is intended to serve as the computational layer for UTXO-based applications across the Apex Fusion ecosystem. We wanted to test whether we could:
- Sustain 4-second block times without compromising consensus stability
- Support high transaction volume under realistic load
- Measure mempool behavior, chain growth, and network sync between nodes
These are non-trivial goals. Cardano’s conservative 20-second block time is a product of rigorous stability and propagation constraints. Reducing that to 4 seconds introduces challenges in propagation, validation concurrency, mempool pressure, and chain selection logic.
Test Environment Setup
We deployed a 6-node testnet using a geographically-constrained topology (Europe-only) to minimize latency as a variable. Nodes were distributed across two cloud providers, with peer topology generated via manual peering.
Each node ran:
- Cardano-node 9.2.1.
- Separate Prometheus instances for metrics
- Additional custom instances for metrics
- Simulated transaction submission agents using TxPipe custom software with realistic wallet state and UTXO sets
Key protocol parameters for this round of testing:
All nodes ran with identical software and synced genesis. Slot leader schedule is randomized, rotating through nodes with uniform probability.
Transaction Generation & Load Profiles
TxPipe created a generator that mimics a range of real-world workloads:
- Simple Load: simple P2P UTXO transfers
- Smart Contract Load: Plutus-like scripts executing a spending validator
- Metadata Load: Metadata-carrying transactions, token minting/burning
These are different scenarios run in independent tests. In the future we plan to run tests that combine different loads and measure the performance.
Get Apex Fusion’s stories in your inbox
Join Medium for free to get updates from this writer.
Transactions were batched and signed offline, then submitted via REST endpoints or local IPC to simulate typical dApp backend behavior.
Observability & Metrics
Prometheus + Grafana dashboards, as well as our custom monitoring software, allowed us to track the following:
- Block propagation time (median and 95th percentile)
- Chain density and block height drift between nodes
- Mempool fullness
- Node CPU/memory under sustained load
- Fork events
For deeper inspection, we also ran post-mortem analysis using:
- Time-to-finality under various fork scenarios (more on this soon)
- Transaction latency end-to-end (submit-to-inclusion)
Early Results
Propagation Times: At all tests performed so far, block propagation stayed under 200ms (95th percentile) which is well within our tolerance window. Tests are not at the highest level of complexity yet, so these results are not final.
Smart Contract Execution: Scripts executed correctly under load.
Node Resource Usage: CPU usage remained stable (avg 30%, spikes to 90%) on 2-core VMs. RAM pressure peaked at 1.0 GB.
What We Learned So Far
- 4-second block time is viable in a geographically optimized network with proper tuning.
- Chain stability holds, provided slot leadership randomness and block size tuning.
- Standard Cardano hardware is probably good enough for Vector, excluding high network speeds and geolocation
Conclusion
Testing is not done yet, there are more things to try and break, more data to be collected and analyzed, but the team is feeling quite confident that Vector will be stable under the given requirements and that there will be some space to increase max execution units and block size down the line. RareEvo is coming and we are aiming to have a public testnet of Vector by then so that you can try it out for yourself.
A thought piece by Filip Blagojević, Director of Delivery at HAL8 and core contributor to Apex Fusion.









