fix(realunit): forward the signed name/address variant to Aktionariat#3839
Merged
Conversation
Aktionariat re-verifies the EIP-712 registration signature against the payload we POST. Wallets sign either the raw UTF-8 fields (legacy software wallets) or the BitBox-safe ASCII transliteration (current app; a BitBox cannot sign non-ASCII bytes), but forwardRegistration always sent the stored UTF-8 fields. ASCII-signed registrations were therefore recovered to a different address and rejected with "Invalid signature", leaving the step in MANUAL_REVIEW. Resolve which variant the signature verifies against and forward exactly those bytes. The UTF-8 originals stay on user_data for PDF/mail. This also unblocks the software-wallet -> hardware-wallet migration path, since both wallet types can produce the ASCII variant.
Drop the verify refactor and keep only the behavioral change: transliterate the free-text fields to BitBox-safe ASCII in forwardRegistration so the payload matches the signed bytes. verifyRealUnitRegistrationSignature is left untouched.
TaprootFreak
changed the title
The minimal "always transliterate to ASCII" approach regressed legacy wallets that signed the raw UTF-8 fields (still accepted by #3709's verify): forwarding ASCII no longer matched their UTF-8 signature. Resolve which representation the signature verifies against (raw or BitBox-safe ASCII) and forward exactly that, so both legacy UTF-8 signers and current ASCII/BitBox signers keep working.
TaprootFreak
changed the title
davidleomay
approved these changes
Jun 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
forwardRegistrationalways sent the stored UTF-8 fields. For an ASCII-signed registration, Aktionariat then recovers a different address and rejects withInvalid signature, leaving the KYC step inMANUAL_REVIEW.user_datafor PDF/mail.Why not "always transliterate to ASCII"
That simpler variant would regress legacy wallets that signed the raw UTF-8 fields (umlaut names): forwarding ASCII would no longer match their UTF-8 signature →
Invalid signature.verifyRealUnitRegistrationSignatureaccepts both representations (#3709), so the forward must preserve both. This change forwards the matched variant, so legacy UTF-8 signers and current ASCII/BitBox signers both keep working.Changes
verifyRealUnitRegistrationSignature→ thin wrapper over a newresolveSignedRegistrationMessage, which returns the exact signed field set (raw or ASCII) orundefined. Behaviorally identical to the previous two-attempt boolean.forwardRegistrationbuilds the Aktionariat payload from the resolved (signed) variant. Field set, types and excludedkycDataunchanged. No schema/migration changes.Test plan
lint,format:check,build, full test suite green locally; independent regression review = NO_REGRESSION.Operational note
Registrations stuck in
MANUAL_REVIEWfor this reason can be drained after deploy via the existing admin re-forward endpoint.