I’ve been conducting a side-by-side audit of the transaction construction logic in both the Ark Labs (arkd) and Second (bark) repositories. I’m currently building a high-performance, no_std Rust library (V-PACK) designed to verify Ark state-trees on resource-constrained devices like hardware wallets.
During my analysis of the current test vectors, I’ve mapped out several deterministic differences that currently prevent the two implementations from being binary compatible. Specifically:
Transaction Templates: While both teams have converged on the 51024e73 Fee Anchor, the number of outputs per virtual transaction differs significantly due to divergent Connector Topologies (Binary Tree vs. Sequential Chain).
Sequence Policies: I’ve found divergences in nSequence usage between implementations (MAX vs. ZERO) and even within the same implementation (MAX for Rounds vs. MAX-1 for OOR payments).
Proof Serialization Format: There is a divergence in how a VTXO is uniquely ‘named’ in code—using a raw 32-byte Hash (TxID) and a 36-byte OutPoint (Hash:Index).
Because even a byte change in these templates results in a completely different ID, a proof generated by one app is currently ‘unreadable’ to another. This creates data silos that could complicate cross-client recovery and makes it difficult for hardware wallets to support the protocol using a single, deterministic signing template.
I am building V-PACK as a generalized abstraction layer to carry the raw ingredients needed to reconstruct these transactions regardless of the specific “dialect” an ASP speaks. As I finalize the logic engines, I have two questions for the teams:
Standardization: Are there any active discussions or plans to move toward a unified “virtual transaction” standard to ensure off-chain state remains portable across different implementations?
Stability: Are the current V3/TRUC templates and data structures considered stable for production, or should we expect significant changes as BIP-431 (TRUC) and other L2 consensus rules evolve?
I’m happy to share the specific forensic deltas I’ve documented if that helps the conversation. My goal for this library is to help develop a robust foundation for the broader Ark ecosystem.
Our low-level library (ark-lib) is built to be performant and very low on resource consumption. It builds for WASM in browsers as well. It is currently not yet compatible with no_std compilation, but it shouldn’t need more than alloc and a solution for the std::io::{Read, Write, Error} usage.
As for differences with the Arkade implementation, since Ark interactions are local to the context of the server, there is not much need for us to standardize VTXO serialization or structure.
We have previously formalized the ark1 address format because we both use that format and they could be displayed to users of either implementation.
While it would help for a tool like yours to have a unified description of off-chain txs, our both teams are in early stages of development and deployment so we prefer to have the flexibility to move fast than to be held back by standards. That position might change in the future, but for now there is no benefit in it for us.
I’m sorry if that means your library would have to implement some things twice. I do however think that once ark-lib compiles to no_std, you would have very little logic to re-implement for our data structures.
Some responses to your individual points
We don’t use connectors anymore in rounds, since our 0.1.0-beta.6 release. It’s correct that we had connector chains before that instead of connector trees.
Please correct me if I’m wrong, but we don’t use nSequence values of MAX-1. The sequence value affects the timelock semantics, so we have to set it to ZERO in transactions where timelocks should be enabled and we set the industry-default of MAX (meaning no replacements allowed) in all other contexts. One exception might be in our wallet itself, where we enable RBF in the exit code, but that is only for CPFP child transactions which are not part of the pre-computed Ark protocol transactions, but local to the wallet only.
Yes since VTXOs refer to virtual “outputs”, we use the “outpoint” format that is also used for UTXOs in bitcoin itself. This is required because in tree structures, multiple VTXOs can share the same leaf txid.
Definitely expect changes once a covenant opcode would be merged, that’s a certainty. As for the current TRUC constructions, I think they’re stable. We’re currently merging code to allow use of the anchor values for fee accounting. But that doesn’t change the policies we are using. All txs will remain zero-fee and have pay-to-anchor fee anchors.
Hope that helps! Definitely feel free to ask more questions, either here or in our chat at chat.second.tech!
Thank you for taking the time to provide such a thorough and technically insightful response. It’s very helpful to get this level of clarity on the current direction of ark-lib and Second’s design philosophy.
I completely understand the preference for flexibility and speed at this early stage. My goal with V-PACK isn’t to slow down development with a rigid committee standard, but to provide a neutral adapter library so third-party tools (like hardware wallets or recovery services) don’t have to choose a side or rebuild logic for every implementation.
Regarding no_std support, I’ll be following your progress on ark-lib closely. In the meantime, I’ll continue focusing on the glue logic that bridges the specific template differences to ensure cross-client state remains verifiable.
I appreciate the invite to the community chat, I’ll definitely drop in there as I get further into the implementation.