Connector Output
A special Bitcoin transaction output used in the Ark protocol to atomically link on-chain and off-chain state transitions, preventing double-spending without Lightning-style penalties.
Key Takeaways
- A connector output is a small-value UTXO (typically at the dust limit) included in an Ark round transaction that creates a spending dependency between on-chain confirmation and off-chain state transitions.
- Connector outputs solve the atomicity problem: a user's forfeit transaction (giving up their old VTXO) is only valid if the round transaction that creates their new VTXOs has confirmed on-chain, ensuring neither side can cheat.
- Unlike Lightning's anchor outputs (which handle fee bumping), connector outputs enforce conditional transaction validity, enabling trustless double-spend prevention without penalty mechanisms.
What Is a Connector Output?
A connector output is a special Bitcoin transaction output used in the Ark protocol to cryptographically bind off-chain VTXO transfers to on-chain transactions. It is a small-value UTXO (often at the dust limit of around 294 sats for SegWit outputs) that carries no meaningful financial value itself. Its purpose is entirely structural: it creates a conditional dependency that makes a forfeit transaction valid only when the corresponding round transaction has been confirmed on the Bitcoin blockchain.
The concept was introduced by Burak Keceli as part of his original Ark protocol proposal on the bitcoin-dev mailing list in May 2023. Connector outputs address a fundamental challenge in shared UTXO models: how do you guarantee that giving up an old off-chain coin and receiving a new one happen atomically, without relying on trusted intermediaries or Lightning-style penalty mechanisms?
For a comprehensive overview of the protocol that uses connector outputs, see the Ark protocol deep dive.
How It Works
Understanding connector outputs requires context on Ark's round-based transaction model. In Ark, an Ark Service Provider (ASP) periodically creates round transactions that batch multiple users' off-chain transfers. Each round replaces old VTXOs (virtual UTXOs) with new ones. The challenge: users must give up their old VTXOs by signing forfeit transactions, but they need assurance that their new VTXOs will actually be created before the forfeits become valid.
Connector outputs solve this in three steps:
- The ASP constructs a round transaction with two output trees: one containing new VTXOs for all participants, and another containing connector outputs (one per input VTXO being consumed)
- Each user signs a forfeit transaction that requires two inputs: their old VTXO and the corresponding connector output from the new round transaction
- The user signs with SIGHASH_ALL, committing to every input in the transaction, making it impossible to substitute or remove the connector input
Because the connector output only exists as a spendable UTXO after the round transaction confirms on-chain, the forfeit transaction cannot be executed unless the new VTXOs have also been created. Either the entire round completes (new VTXOs created and old VTXOs forfeitable) or nothing happens.
Round Transaction Structure
A round transaction created by the ASP follows a specific structure. Its inputs come from the ASP's liquidity pool. Its outputs fan out into two covenant trees:
Round Transaction
├── Inputs: ASP liquidity UTXOs
├── Output 1: VTXO covenant tree
│ ├── Leaf A: (Alice + ASP) OR (Alice after timeout)
│ ├── Leaf B: (Bob + ASP) OR (Bob after timeout)
│ └── Leaf C: (Carol + ASP) OR (Carol after timeout)
└── Output 2: Connector output tree
├── Connector A: singlesig(ASP), ~294 sats
├── Connector B: singlesig(ASP), ~294 sats
└── Connector C: singlesig(ASP), ~294 satsEach connector output is a singlesig output spendable only by the ASP. The connector tree mirrors the input VTXOs: one connector per VTXO being consumed in the round.
Forfeit Transaction Structure
For each input VTXO, the user pre-signs a forfeit transaction before the round is broadcast:
Forfeit Transaction (pre-signed by user)
├── Input 1: Old VTXO (spent via User + ASP multisig path)
├── Input 2: Connector output from round tx (spent by ASP)
└── Output: Old VTXO value → ASPThe user's SIGHASH_ALL signature covers both inputs. The ASP later co-signs by providing its signature on the multisig VTXO input and the singlesig connector input. But the ASP can only do this after the round transaction confirms, because the connector UTXO does not exist until then.
Why Connector Outputs Prevent Double-Spending
Lightning Network channels use a penalty-based system to prevent double-spending: if one party broadcasts a revoked commitment transaction, the counterparty can claim all funds via a justice transaction. This requires constant monitoring (or watchtowers) and creates a game-theoretic deterrent.
Ark's connector output mechanism takes a fundamentally different approach: forfeit-based revocation.
- Once a user signs a forfeit transaction for their old VTXO, they have pre-authorized the ASP to claim those funds, but only conditional on the round confirming
- If the user later tries to unilaterally exit their old VTXO on-chain (a double-spend attempt), the ASP broadcasts the forfeit transaction to claim those funds, since the round has already confirmed and the connector output exists
- If the user does not attempt to double-spend, the forfeit transaction is never broadcast, and the old VTXO simply expires after the timeout period (typically four weeks)
The forfeit transaction is not a punishment for misbehavior: it is a pre-authorized conditional transfer. There is no penalty multiplier, no need for continuous watchtower monitoring, and no game-theoretic bluffing. The mechanism is deterministic: the connector dependency guarantees atomicity, and the forfeit provides the ASP's insurance against double-spending.
Connector Outputs vs. Anchor Outputs
Both connector outputs and anchor outputs are small-value UTXOs in layer-2 protocols, but they solve entirely different problems:
| Aspect | Connector Output (Ark) | Anchor Output (Lightning) |
|---|---|---|
| Purpose | Enforces atomicity between forfeit and round transactions | Enables fee bumping of commitment transactions via CPFP |
| Value | ~294 sats (dust limit) | 330 sats |
| Who can spend | ASP only (singlesig) | Either channel party |
| Security role | Prevents premature VTXO forfeiture | Ensures commitment transactions confirm in high-fee environments |
| Mechanism | Transaction input dependency (SIGHASH_ALL) | Child-Pays-For-Parent fee bumping |
Anchor outputs were introduced in Lightning to address the problem of pre-signed transactions becoming unconfirmable when on-chain fees spike. Connector outputs address a structural problem unique to shared UTXO models: ensuring that state transitions happen atomically across on-chain and off-chain layers.
Use Cases
Ark Round Participation
The primary use case for connector outputs is in standard Ark rounds. Every time a user transfers VTXOs through the ASP, connector outputs ensure the transfer is atomic. The user can safely sign a forfeit for their old VTXO knowing it cannot be executed unless they receive new VTXOs in the same round.
Connector Swaps
Connector outputs can also facilitate atomic swaps between protocols. By using a connector output as one input to a swap transaction, two parties can ensure that a cross-protocol exchange is conditional on on-chain confirmation. This is conceptually similar to how HTLCs enable atomic swaps on Lightning, but uses transaction structure rather than hash-locked contracts.
Offboard Payments
When users want to move funds from Ark back to the Bitcoin base layer (offboarding), connector outputs ensure that the on-chain payment and the VTXO consumption happen atomically. The user does not risk losing their VTXO without receiving the on-chain payment.
Evolution and Protocol Improvements
The connector output mechanism has evolved since Ark's initial design:
- Ark v0.5.0 replaced the original linear connector chain with a connector tree structure, reducing the signing burden to one forfeit transaction per VTXO instead of requiring each forfeit to reference a chain of prior connectors
- Ark V2 proposed introspection-based connectors using OP_CHECKSIGFROMSTACK, which could work with the revocation mechanism that changes VTXO outpoint references
- Some implementations have explored hash-lock alternatives for specific operations like VTXO refreshes, where both the new VTXO and forfeit are hash-locked until the ASP reveals a preimage
Future Bitcoin covenant opcodes could enhance connector outputs further. SIGHASH_ANYPREVOUT (BIP-118) could enable non-interactive round participation by allowing connectors to bind to any transaction matching a given template, removing the requirement for all users to be online simultaneously during a round. OP_CHECKTEMPLATEVERIFY (BIP-119) could constrain transaction outputs directly, streamlining the connector mechanism.
Risks and Considerations
ASP Trust Assumptions
Connector outputs are singlesig, spendable only by the ASP. If the ASP colludes or acts maliciously, the connector mechanism alone does not protect users. However, users retain the ability to unilaterally exit their VTXOs on-chain after the timeout period, which bounds the damage an ASP can cause. The ASP cannot steal funds: at worst, it can refuse to cooperate and force users to wait for timeout-based recovery.
On-Chain Footprint
Each Ark round produces a connector output for every input VTXO being consumed. While each connector is small (dust-limit value), rounds with many participants create proportionally more on-chain data. The move from linear connector chains to connector trees in v0.5.0 improved efficiency, but large rounds still require significant block space for the connector tree.
Interactivity Requirement
Without covenant opcodes, all VTXO recipients in a round must co-sign the round transaction, meaning they must be online simultaneously. This is a practical constraint that covenant proposals like APO and CTV could address by allowing connector outputs to reference transaction templates rather than specific transaction IDs.
Timeout and Liquidity
VTXOs created in a round expire after a timeout period (typically four weeks). Before expiry, users must participate in a new round to refresh their VTXOs, or unilaterally exit on-chain. This creates a recurring liquidity requirement for both users and the ASP that does not exist in Lightning channels, where state can persist indefinitely.
This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.