From 25534dbadb4185591994aa1acd94e68e1559d17d Mon Sep 17 00:00:00 2001 From: bfoss765 <38437574+bfoss765@users.noreply.github.com> Date: Sun, 9 Aug 2026 17:03:45 -0400 Subject: [PATCH] fix(platform-wallet): raise the invitation cap to cover the contested username tier MAX_INVITATION_DUFFS 5_000_000 -> 26_000_000 (0.05 -> 0.26 DASH). Required for existing Android functionality: the Android wallet has funded contested (premium-name) invitations at 0.25 DASH since 2024 (DASH_PAY_FEE_CONTESTED, dash-wallet Constants.java). Its legacy dashj path imposes no cap, so contested invitations have always worked pre-cutover; the moment a wallet commits the dashj->SDK cutover, create_invitation becomes the only route and every contested invitation is rejected pre-broadcast with 'invitation amount 25000000 exceeds the cap 5000000 duffs' - observed on device 2026-08-09, an endless-retry loop in the field. The 0.05 value's own doc deferred the contested tier 'until contested-name-via-invite claim exists; raise this cap when it does'. That condition is met: claim_invitation is amount-agnostic and contested-invite claims are verified working in QA. The cap remains a client-side leaked-link bound, not consensus; both the dashj and shielded invitation paths already mint 0.25 bearer links today, so 0.05 here protected nothing while breaking path parity. 0.26 = 0.25 contested fee + margin for the create/claim fees, matching the Android wallet's rounded contested guidance. Co-Authored-By: Claude Fable 5 --- .../src/wallet/identity/network/invitation.rs | 20 +++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/packages/rs-platform-wallet/src/wallet/identity/network/invitation.rs b/packages/rs-platform-wallet/src/wallet/identity/network/invitation.rs index 760b039bec..8f3a41ef60 100644 --- a/packages/rs-platform-wallet/src/wallet/identity/network/invitation.rs +++ b/packages/rs-platform-wallet/src/wallet/identity/network/invitation.rs @@ -45,15 +45,19 @@ use crate::wallet::identity::network::contact_requests::ContactCryptoProvider; use super::*; -/// Hard cap on the amount an invitation can lock (0.05 DASH). The voucher is a +/// Hard cap on the amount an invitation can lock (0.26 DASH). The voucher is a /// bearer credential, so the blast radius of a leaked link is bounded here in -/// Rust — not just in the UI. Sized for onboarding: the invitee spends the -/// voucher on identity creation **plus** a normal DPNS name (~0.03 DASH — the -/// legacy `DASH_PAY_FEE`), so the previous 0.01 cap was actually below a usable -/// invitation and rejected its own onboarding default. The contested/premium-name -/// tier (~0.25 DASH) is deferred until contested-name-via-invite claim exists; -/// raise this cap when it does. -pub const MAX_INVITATION_DUFFS: u64 = 5_000_000; +/// Rust — not just in the UI. Sized for onboarding at BOTH username tiers: the +/// invitee spends the voucher on identity creation **plus** a DPNS name — a +/// normal name (~0.03 DASH, the legacy `DASH_PAY_FEE`) or a contested/premium +/// name (~0.25 DASH, `DASH_PAY_FEE_CONTESTED`), with the 0.01 margin covering +/// the create/claim fees. The earlier 0.05 value deferred the contested tier +/// "until contested-name-via-invite claim exists" — the claim path is +/// amount-agnostic and contested-invite claims are verified working, and the +/// Android wallet has funded contested invitations at 0.25 since 2024, so the +/// deferral is over. (The pre-merge 0.01 iteration was below even a usable +/// non-contested invitation and rejected its own onboarding default.) +pub const MAX_INVITATION_DUFFS: u64 = 26_000_000; /// Floor on the amount an invitation can lock (0.003 DASH). A voucher funds a /// Platform identity operation, and creating an identity — which is what the