Found while casting the first rc2 vote on devnet (2026-08-07), using the form added in #255.
What happens
In the Setup Coupon Reassignment Delegation form, the Beneficiary Party field shows only the first ~18 characters. A row reads:
The Assigner fields on the same form are much wider and do not have this problem. The beneficiary row is cramped because it shares a flex row with the Weight field, the derived-decimal readout and a Remove button.
Why it matters more here than it looks
A typo in a beneficiary party bricks the delegation for its lifetime. The propose boundary cannot check party existence — that was assessed and filed as won't-fix — so the form is the last place a mistake is catchable, and right now it is not visually verifiable.
It is worse than a generic truncation because of an actual collision on devnet:
attestor-1::1220fa8543db6c66fe3a55b1f180c8dfc7f876265c76684fbc1d35d89e02c8aafe8e
cbtc-beneficiary::1220fa8543db6c66fe3a55b1f180c8dfc7f876265c76684fbc1d35d89e02c8aafe8e
Same namespace, different party. The visible prefix is the only thing distinguishing them, and pasting the wrong one produces a delegation that looks right and pays the wrong party.
Fix
Options, cheapest first:
- Give the beneficiary row the same width treatment as the assigner rows — move the derived decimal onto its own line beneath, or widen the party field and shrink the weight field, which only ever holds a small integer.
- Show the full party id in a tooltip or
title attribute on hover.
- Render a truncated-middle display (
attestor-1::1220fa…aafe8e) so both ends are visible, which is what distinguishes colliding ids.
(3) plus (1) would settle it. The same treatment would suit the Assigner rows for consistency.
Not urgent
The first rc2 vote went through correctly — the values were pasted, and the resulting on-ledger split was verified against PQS. This is about making the next one verifiable by eye rather than by trust.
Found while casting the first rc2 vote on devnet (2026-08-07), using the form added in #255.
What happens
In the Setup Coupon Reassignment Delegation form, the Beneficiary Party field shows only the first ~18 characters. A row reads:
The Assigner fields on the same form are much wider and do not have this problem. The beneficiary row is cramped because it shares a flex row with the Weight field, the derived-decimal readout and a Remove button.
Why it matters more here than it looks
A typo in a beneficiary party bricks the delegation for its lifetime. The propose boundary cannot check party existence — that was assessed and filed as won't-fix — so the form is the last place a mistake is catchable, and right now it is not visually verifiable.
It is worse than a generic truncation because of an actual collision on devnet:
Same namespace, different party. The visible prefix is the only thing distinguishing them, and pasting the wrong one produces a delegation that looks right and pays the wrong party.
Fix
Options, cheapest first:
titleattribute on hover.attestor-1::1220fa…aafe8e) so both ends are visible, which is what distinguishes colliding ids.(3) plus (1) would settle it. The same treatment would suit the Assigner rows for consistency.
Not urgent
The first rc2 vote went through correctly — the values were pasted, and the resulting on-ledger split was verified against PQS. This is about making the next one verifiable by eye rather than by trust.