Send it. Sleep on it. Take it back.
Reversible transfers are Quantus's signature safety feature: every transfer can be scheduled with a delay, held in escrow by the protocol, and cancelled before it executes — by you, or by a guardian you appoint. Enroll in high-security mode and your account can only make reversible transfers, enforced at the transaction level. This desk plans delays, builds the exact unsigned call data, simulates the quota and the 1% reversal fee, and watches the live queue. It never signs anything.
The lifecycle click each stage for the exact mechanics
A reversible transfer is a five-act play. Funds are never "sent and hoped for" — they are held, then either released to the destination or returned. Tap a stage.
Delay planner build the exact unsigned call data
Compose a reversible transfer. The desk validates the delay against the on-chain minimum (≥ 2 blocks / ≥ 12 000 ms), estimates the execute-at block from the live height, and emits the exact SCALE call data — pallet 11, the right call index, MultiAddress::Id destination, plain-u128 amount — ready to paste into Chain Console or your signer.
DefaultDelay). High-security accounts ignore this and use their configured delay.High-security enrollment the one-way door
⚠ PERMANENT AND IRREVERSIBLE — read this before you build the call below
Calling set_high_security cannot be undone. Afterwards your account can only schedule_transfer, cancel, and recover_funds — enforced by the transaction extension, not by convention. An attacker holding your key cannot disable it, which is the point — but neither can you.
- Your guardian gains instant, total power: cancel any pending transfer (1% burn, remainder to them) and
recover_fundsto sweep the entire account at any time, repeatedly, with no second approver. - Guardian cannot be yourself. Guardian cannot be changed afterwards.
- Use a multisig address as guardian — the pallet docs say so explicitly, and a single-key guardian shares your 16-tx/day quota and can be locked out of rescuing you.
Build the enrollment call. The desk validates the guardian address, the self-guardian rule, and the delay — then emits the exact unsigned set_high_security call data.
Quota simulator 16 extrinsics per rolling 24 hours
High-security accounts are rate-limited: at most 16 signed extrinsics per rolling 7 200-block window, tracked in a ring — room opens only when the oldest entry ages out. Non-high-security accounts are unlimited. Add simulated transactions and watch the window fill; the simulator uses the live chain height.
Documented edge case: the quota keys on the outer signer, so a single-key high-security guardian shares the quota with its own traffic and can be locked out of cancel/recover_funds for up to a day. A multisig guardian's derived address never signs, so it is immune.
Reversal-fee calculator the 1% that burns
Reversing a high-security transfer burns HighSecurityVolumeFee = Permill::from_percent(1) of the amount — exactly 1%, integer floor. One-time schedules reverse fee-free. This is the price of the rescue.
Guardian console what the guardian can actually do
The guardian is not a co-signer — they are a unilateral rescue key. Two powers, no approval needed from the account owner:
| Power | Who can call it | What happens, exactly |
|---|---|---|
cancel(tx_id)pallet 11, call 1 |
Only the guardian recorded at schedule time (frozen — a later set_high_security can't rewrite it) |
The hold is released: 1% of the amount is burned, the remaining 99% is transferred to the guardian (not back to the sender). Scheduler task cancelled best-effort. For one-time schedules the sender cancels instead, fee-free, funds return to sender. |
recover_funds(account)pallet 11, call 7 |
Only the account's live guardian | Seize-the-account: every pending transfer is cancelled (1% burn each), then the entire free balance is swept to the guardian. Best-effort per transfer — failures are skipped with a TransferRecoveryFailed event, never rolled back. Repeatable: the account stays high-security, so future deposits remain recoverable. Guardianship is discoverable off-chain via the HighSecuritySet event. |
The guardian checklist
- Use a multisig as guardian. The pallet docs recommend it verbatim; a multisig dispatches as its derived address and can cancel/recover exactly like a plain account — with no single point of failure and no quota lockout.
- Guardian ≠ you, forever. Self-guardianship is rejected on-chain (
GuardianCannotBeSelf), even at genesis — a self-guardian would silently void all protection. - Expect the 1%. Every guardian-initiated reversal burns 1% and pays the other 99% to the guardian, who must forward it to you off-chain. Put that agreement in writing before you enroll.
- Keep the guardian's key safer than yours. It can drain the account in one call. A lost guardian key doesn't lock you out (you can still schedule and wait), but a stolen one ends the account.
- High-security accounts can batch. A flat, non-nested
batch_allof up to 16 whitelisted calls (schedule/cancel/recover) is allowed — handy for scheduling several transfers in one of your 16 daily extrinsics.
Call reference exact indices for offline builders
Pallet ReversibleTransfers sits at runtime index 11 (runtime/src/lib.rs). All of the following verified at Quantus-Network/chain rev 482c5b9.
| Call | Index | Args (SCALE) | Who |
|---|---|---|---|
set_high_security | 0 | delay: BlockNumberOrTimestamp (0x00‖u32 LE blocks | 0x01‖u64 LE ms), guardian: AccountId (32 B) | any account, once — one-way |
cancel | 1 | tx_id: H256 (32 B) | sender (one-time) or guardian (HS) |
execute_transfer | 2 | tx_id: H256 | scheduler only (pallet origin rtpallet) |
schedule_transfer | 3 | dest: MultiAddress (0x00‖32 B), amount: u128 not compact (16 B LE) | high-security accounts (uses configured delay) |
schedule_transfer_with_delay | 4 | as above + delay: BlockNumberOrTimestamp | regular accounts only |
| indices 5–6 | — | vacant (asset-transfer calls removed; kept stable so recover_funds stays at 7) | |
recover_funds | 7 | account: AccountId (32 B) | the account's guardian |
High-security transaction rules
- Whitelist:
schedule_transfer(dest must beMultiAddress::Id— a stolen key can't padRawto inflate the length fee),cancel,recover_funds, or a flat non-nestedbatch_allof ≤ 16 of those. - Quota: 16 signed extrinsics per rolling 7 200 blocks (~24 h). Tip: forced to zero. Size: extrinsics capped at 10 KiB encoded.
- Delay bounds: ≥ 2 blocks or ≥ 12 000 ms. Default delay: 7 200 blocks. Max 16 pending transfers per account.
- Execution: the scheduler dispatches
execute_transferas the pallet's sovereign account; the inner transfer istransfer_allow_death— a broke sender still completes.
Live queue every reversible transfer the indexer has seen
Read from the same-origin snapshot of the public Subsquid indexer. The delay itself lives in the TransactionScheduled event args, which the snapshot doesn't carry — so this is the what, not the when.
Scheduled
| tx_id | Amount | From | To | When |
|---|
Cancelled
| tx_id | Cancelled by | When |
|---|
Executed
| tx_id | Result | When |
|---|
High-security enrollments
| Account | Guardian | Delay | When |
|---|
Methodology & honesty read this before quoting
What is exact
- Every constant on this page — pallet index 11, call indices 0/1/2/3/4/7, the 2-block / 12 000 ms minimums, the 16-pending cap, the 16-per-7 200-block quota, the 1% burn, the 7 200-block default delay — is read from Quantus-Network/chain rev
482c5b9(pallets/reversible-transfers,runtime/src/lib.rs,runtime/src/configs/mod.rs). - The call-data encoders reproduce the SCALE layout field-for-field:
MultiAddress::Id=0x00‖32 B,amount= plain u128 LE (the field is not#[pallet::compact]),BlockNumberOrTimestamp=0x00‖u32 LE |0x01‖u64 LE. 49/49 node tests green. - Live queue: real rows from the public Subsquid indexer via the same-origin snapshot.
What is estimated
- Execute-at blocks and wall-clock ETAs assume the 12 000 ms target block time; real blocks vary.
- Timestamp-delay scheduling rounds up to bucket boundaries on-chain; the planner shows your raw delay.
- Pending = scheduled − cancelled − executed is an indexer-derived figure; a transfer cancelled and re-scheduled keeps distinct tx_ids, so counting is by event, not by funds.
What we did not do
- No signing, no key handling, no "connect wallet" — this desk builds unsigned call data only. Verify the hex in Extrinsic Lab before submitting it anywhere.
- No invented CLI commands — the desk emits call data, not
quantus-cliinvocations, because the CLI surface wasn't re-verified for these calls. - No advice on whether you should enroll in high-security mode — the one-way warning is the advice.