Current status
PR #617 removed the original deterministic lifetime limit for unordered channels. A permissionless authenticated transition can now prune a finalized unordered packet receipt and acknowledgement pair after Cardano verifies that the corresponding source commitment no longer exists at a sufficiently recent counterparty height. The transition advances an on-chain proof floor at the same time, so deleting the retained pair does not make an old packet proof replayable.
The matching Hermes integration provides hermes tx packet-prune. An unordered channel therefore no longer has to stop after roughly 32 inbound packets, provided finalized history is pruned in time.
The 64-entry combined datum cap still exists. Ordered receives retain an acknowledgement entry, and the current pruning transition explicitly rejects ordered channels. An otherwise healthy ordered channel can therefore still stop after at most 64 inbound receives, or earlier while outbound commitments are present.
Unordered pruning is also currently an operator-invoked command rather than an automatic capacity-management process. A busy channel can still reach the cap if nobody notices and submits pruning transactions before the remaining capacity is exhausted.
Remaining scope
Complete the packet-state lifecycle for ordered channels and make cleanup proactive for both channel types. The solution must retain replay protection and authoritative on-chain state without introducing a required off-chain database.
Acceptance criteria
- Add a safe authenticated way to remove finalized ordered-channel acknowledgement history, or implement another bounded-state or authenticated-rotation design that gives ordered channels an indefinite operational lifetime.
- Preserve ordered sequence guarantees and reject replayed packet, acknowledgement, and timeout proofs after cleanup.
- Integrate packet-history cleanup into normal relayer operation so eligible unordered and ordered history is pruned before the channel reaches the cap.
- Use a configurable safety threshold with enough remaining capacity for cleanup transactions and packets already in flight.
- Make automatic cleanup idempotent and resumable across relayer restarts, and safe when multiple permissionless relayers attempt the same cleanup.
- Fail safely when the required counterparty non-membership proof is not yet available, then retry without corrupting or losing packet state.
- Add end-to-end tests that process substantially more than 64 inbound packets on both unordered and ordered channels while also exercising sends, acknowledgements, timeouts, relayer restart, and continued transfer afterward.
- Verify through those tests that no escrow, voucher, packet commitment, or replay-protection state is stranded or weakened.
- Measure the cleanup transaction and channel datum at the capacity boundary and keep both within the supported Cardano transaction budget.
- Document the automatic behavior, operator diagnostics, manual recovery command, and any deployment or channel-schema migration requirements.
Current status
PR #617 removed the original deterministic lifetime limit for unordered channels. A permissionless authenticated transition can now prune a finalized unordered packet receipt and acknowledgement pair after Cardano verifies that the corresponding source commitment no longer exists at a sufficiently recent counterparty height. The transition advances an on-chain proof floor at the same time, so deleting the retained pair does not make an old packet proof replayable.
The matching Hermes integration provides hermes tx packet-prune. An unordered channel therefore no longer has to stop after roughly 32 inbound packets, provided finalized history is pruned in time.
The 64-entry combined datum cap still exists. Ordered receives retain an acknowledgement entry, and the current pruning transition explicitly rejects ordered channels. An otherwise healthy ordered channel can therefore still stop after at most 64 inbound receives, or earlier while outbound commitments are present.
Unordered pruning is also currently an operator-invoked command rather than an automatic capacity-management process. A busy channel can still reach the cap if nobody notices and submits pruning transactions before the remaining capacity is exhausted.
Remaining scope
Complete the packet-state lifecycle for ordered channels and make cleanup proactive for both channel types. The solution must retain replay protection and authoritative on-chain state without introducing a required off-chain database.
Acceptance criteria