SendFaultReason enum - send_state library

Values

addressInvalid → const SendFaultReason: The address didn't parse for this network.
memoToTransparent → const SendFaultReason: A memo was given but the recipient can't receive one (transparent).
memoTooLong → const SendFaultReason: The memo exceeds its ZIP-302 length bound.
memoNotSendable → const SendFaultReason: The memo is otherwise un-sendable (reserved framing / bad bytes).
memoConflict → const SendFaultReason: TWO memos were attached to one payment — a text memo AND host machine bytes. A programming error in the app, not something the user did or can fix, which is why it does not share memoNotSendable's "remove it and try again" copy: neither memo is individually invalid, and telling the user their memo is corrupt is wrong for both audiences ( post-build review; it rode MemoInvalid/RW-PAY-006 until an earlier revision).
amountOutOfRange → const SendFaultReason: The composed amount is out of range per the SDK (post-encode).
networkMismatch → const SendFaultReason: The address is for a different network than this wallet.
uriInvalid → const SendFaultReason: The composed payment URI was rejected (oversized/malformed).
notSyncedYet → const SendFaultReason: The wallet isn't synced far enough to anchor a proposal yet — wait for sync, or queue the send for later. The offline-first fork's trigger.
networkUpgradeUnsupported → const SendFaultReason: The Zcash network was upgraded and this app version can no longer build a transaction the network will accept (RW-SYNC-002). NOT a sync problem and NOT the user's doing: waiting changes nothing, only an app update does. Distinct from notSyncedYet for exactly that reason — telling someone to wait for a sync that will never help is the silence this whole feature exists to end.
amountsExpired → const SendFaultReason: A REVIEWED proposal's anchor went stale between confirm and send — the TTL ran out while the user deliberated (the large-amount confirm dialog widens this window). Distinct from notSyncedYet: the wallet IS synced; the NUMBERS expired, so the honest action is "review the payment again", not "wait for sync / queue". (Only the SEND path maps here; on the propose path the same kind means "can't anchor yet" → notSyncedYet.)
queueFull → const SendFaultReason: The durable offline queue is at capacity — let it drain, then retry.
walletBusy → const SendFaultReason: The wallet is mid-lifecycle (closing/repairing), or its store lost a write race to a concurrent sync commit past the SDK's own bounded retry (storeBusy — transient, nothing was written) — retry in a moment.
storageFull → const SendFaultReason: The device is out of disk space, so persisting the send hit DiskFull (#373 — the send sibling of the rescan needsSpace / onboarding storageFull cue). Retrying WITHOUT freeing space deterministically re-fails, so the copy asks for space instead of "try again"; routed BACK TO THE FORM (orange-transient, funds untouched — nothing was written or broadcast), never the red "couldn't complete" dead-end that would loop.
oneTimeAddressLimit → const SendFaultReason: Too many one-time (ephemeral) addresses are still in flight to start another multi-step (TEX) send — the engine gap-limit ceiling. TRANSIENT: a mined forward frees a slot. (2e-2b-v-5a: LIVE — the create/sign path reserves an ephemeral for every two-step TEX now that the slice-A gates are off.)
couldNotPrepare → const SendFaultReason: Couldn't prepare the payment for a reason with no finer mapping that is DETERMINISTIC on the input — retrying unchanged re-fails, so the copy asks the user to check the details. The retryable class is couldNotPrepareTransient (INC-018 (b)).
couldNotPrepareTransient → const SendFaultReason: Couldn't prepare the payment because of a condition the wallet's OWN state clears without the user changing anything — a note whose witness the scan has not completed, an anchor not yet recorded, an input a concurrent proposal holds (WalletErrorKind.proposeTransient, INC-018 (b), phase-2 P2-2). The copy says "try again in a moment" and NEVER "check the details": on the device proof the details were correct and the identical send proposed fine two minutes later. TRANSIENT (orange).
walletUnavailable → const SendFaultReason: No live wallet session (defensive — the screen is gated to an active wallet, so this is a "go back and try again", never expected).
watchOnly → const SendFaultReason: This wallet is WATCH-ONLY — it holds a viewing key but no spending keys, so it can never sign a send (#397 §3.7 D3, RW-VIEW-001). DEFENSE-IN-DEPTH: the wallet-screen chrome hides Send and the send screen re-gates on the watch-only kind, so this is unreachable on the normal path; the arm exists so a deep-link/race that DID reach propose/send surfaces the honest "this wallet can't send" rather than the generic couldNotPrepare (security-N2). Not fixable on the form — the copy states the permanent fact.

Properties

hashCode → int: The hash code for this object.
no setterinherited
index → int: A numeric identifier for the enumerated value.
no setterinherited
name → String: Available on Enum, provided by the EnumName extension
The name of the enum value.
no setter
runtimeType → Type: A representation of the runtime type of the object.
no setterinherited

Methods

noSuchMethod(Invocation invocation) → dynamic: Invoked when a nonexistent method or property is accessed.
inherited
toString() → String: A string representation of this object.
inherited

Operators

operator ==(Object other) → bool: The equality operator.
inherited

Constants

values → const List<SendFaultReason>: A constant List of the values in this enum, in order of their declaration.