Verus request QR creator · request families in practice
A reading course through the Verus Request QR Creator: how each request tab builds its VDXF details object, what its flags mean, and how the signed request becomes a QR code a wallet can act on.
Every tab does the same four things: validate input, build a details object, wrap it in a
GenericRequest, sign and encode. What varies is the details class, the flags, and — twice —
that more than one detail is needed.
| Tab | Details class | Notable additions |
|---|---|---|
| Update Identity | IdentityUpdateRequestDetails | Built from CLI-shaped JSON |
| Service signer | IdentityUpdateRequestDetails | Service key, generated request id, callback + status |
| Authentication | AuthenticationRequestDetails | Recipient constraints (ID / system / parent) |
| Invoice | VerusPayInvoiceDetails | Optional signature; payment-policy flags |
| App Encryption | AppEncryptionRequestDetails | Auth detail first; round-trip verification |
| Data Packet | DataPacketRequestDetails | Six flags; URL descriptor; flag workaround |
| User Data | UserDataRequestDetails | Requested keys; full/partial modes |
| Attestation | DataPacketRequestDetails | signdata → MMRDescriptor + SignatureData → DataDescriptor |
| TX Signing | GeneralTypeOrdinalVDXFObject | JSON payload in a general-purpose object |
| You want to… | Go to |
|---|---|
| Understand how any tab works | 02, then the tab's chapter |
| Build a new tab | 02 → 03 → 12 |
| Debug a QR the wallet rejects | 02 (signing + redirects), then the tab |
| Understand attestations | 10 (and 08 first) |
| Understand the byte-level meaning | the companion primitives book |
This book reads the repository as it stands on main, including the transaction-signing
tab that post-dates the original tab set. Behaviour described here is the app's wiring of the
primitives, not a specification of the wallet's handling — where the two could differ, the text says
so.