Glossary

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:

  1. 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)
  2. Each user signs a forfeit transaction that requires two inputs: their old VTXO and the corresponding connector output from the new round transaction
  3. 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 sats

Each 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 → ASP

The 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.

  1. 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
  2. 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
  3. 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:

AspectConnector Output (Ark)Anchor Output (Lightning)
PurposeEnforces atomicity between forfeit and round transactionsEnables fee bumping of commitment transactions via CPFP
Value~294 sats (dust limit)330 sats
Who can spendASP only (singlesig)Either channel party
Security rolePrevents premature VTXO forfeitureEnsures commitment transactions confirm in high-fee environments
MechanismTransaction 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.