Rust Transfer System — Self-Custody + Treasury + Multi-Sig + Shielded + Stealth + Phase 29 Biometric Defense
Initializing…
🎛️ CockpitUnified dashboard across all 28 phases of the Rust Transfer System
「Don't trust, compute. The computation was perfect.」
Ed25519 signatures + SHA-256 chain + Pedersen Commitments + Merkle Tree + Nullifier Set + Stealth Address + Atomic Lua — all 27 phases are running concurrently on this server.
🏛 Treasury0.01% transfer fee / cap 100 trillion units
0 JPY
Cap 100,000,000,000,000 JPY
💸 Collecting 0.01% fee
00.00%100T
🔑 My WalletHold multiple keys. Also used for multi-sig and HTLC signing.
No wallets yet.
The radio-selected wallet is the "active" one (sender for single-signer transfers).
📝 Pick an account name to registerBind a name to your active key
📊 Ledger
⏳ Pending time-locked transfers
🤝 Joint Account (Multi-Sig Vault)Vault protected by M-of-N signatures
A shared vault that only releases funds when at least the threshold (M) number of members have signed.
Existing joint accounts
💎 Payment ChannelsOff-chain scaling between two parties (Layer 2)
📖 How it works: open a 2-of-2 joint account as a channel. Day-to-day payments are signature exchanges inside the browser (off-chain); only the final result is committed to the chain.
⚡ Even with 100 transfers, only 1 open block + 2 settlement blocks = 3 blocks total hit the chain.
🔐 Each off-chain state is locked by a sequence number + both parties' Ed25519 signatures, so it cannot be repudiated later.
Open a new channel (requires an existing 2-of-2 vault)
Paid automatically to a successful defender only
※ A + B + bounty must equal the vault's current balance. Pre-deposit the bounty into the vault as well.
Active channels
⚖️ Channel Disputes (Unilateral Close)"Recover funds even if the counterparty disappears"
📖 How it works: when cooperation breaks down, submit the latest "both-signed state" you hold as a chan_close block on chain.
🕐 Dispute window: for 10–300 seconds after submission, the other party can post a counter-proposal with a higher seq.
🛡️ Anti-fraud: if you try to close with a stale state (back when your balance was higher), the other party can dispute with the latest state — the chain auto-corrects to the right split.
💯 Outcome: after the window, the highest-seq split is enforced mathematically → vault → A / B auto-distribution.
📖 Phase 13b: the primary node (write-enabled) is followed by mirror nodes that poll /sync/state?since=N for delta blocks. Each node has its own independent Redis.
🔐 Trust minimization: a mirror does not simply trust the blocks it receives. It re-runs apply_blocks_to_state locally (signatures + balances + chained hashes); only if everything verifies does it append to its own chain. Even a malicious primary cannot push a lie.
🛟 Phase 13c self-promotion: mirrors keep probing the primary's /health. After AUTO_PROMOTE_AFTER_FAILURES consecutive failures, the mirror auto-promotes to PRIMARY. Set to 0 to disable auto-promote and only allow manual POST /admin/promote.
📜 Audit log: promotion events are appended to Redis (replication:promotion_log) and survive restarts. You can verify when, why, and at what height any promotion happened.
🔭 Phase 13d fence token: every node carries an epoch (monotonic u64). Each promotion does INCR replication:epoch and pushes the new epoch to peers. Any node with a stale epoch immediately self-fences, so all writes return 503. This mathematically eliminates split-brain.
📐 Safety property: epoch is monotone, fence is one-way (a fenced node cannot un-fence without restart). This minimizes the window where two nodes claim PRIMARY simultaneously, and on detection both halt.
🔧 Mirror launch example (including 13d):BIND_ADDR=127.0.0.1:3001 REDIS_URL=redis://127.0.0.1:6380/ PRIMARY_SOURCE_URL=http://127.0.0.1:3000 AUTO_PROMOTE_AFTER_FAILURES=5 PEER_URLS=http://127.0.0.1:3000 FENCE_PROBE_INTERVAL_MS=5000 cargo run
🏛 Mode
—
—
⛓ Sync progress
—
local / primary
⏱ Last sync
—
— successes
🚨 Sync errors
0
no errors
🛟 Health fails / auto-promote
— / —
primary OK
✍️ Writable?
—
—
📜 Most recent promotion
never
—
🔢 Epoch (fence token)
—
peers: —
🚧 Fence 状態
正常
peer 観測中
Manual promote appears only when MIRROR_FOLLOWING and primary unreachable
🔬 Phase 22: ZKP — Pedersen Commitment + Schnorr Proof"Reveal nothing of the secret, only the truth"
📖 Pedersen Commitment:C = v·G + r·H (ristretto group). v is the committed value and r a random blinding factor. H is a nothing-up-my-sleeve generator independent of G.
🔐 Hiding: With a fresh random r, v can never be recovered from C (information-theoretic hiding).
🪢 Binding: Once published, C uniquely determines (v, r). You can never claim a different value later (hard from discrete log).
✅ Schnorr knowledge proof: Prove "I know the (v, r) behind C" without leaking either. Sigma-protocol + Fiat-Shamir = non-interactive.
🪞 Schnorr equality proof: Prove "C₁ and C₂ commit to the same value" without disclosing it. Observation: C₁ − C₂ = (r₁ − r₂)·H (the v-term cancels).
🚀 Future: Layered with range proofs (bulletproofs), these primitives evolve into real Confidential Transactions where balances and amounts stay encrypted yet verifiable.
1. Pedersen commit + knowledge proof
commitment_hex:
blinding_hex (secret):
proof.t:
proof.s_v:
proof.s_r:
2. Verify the knowledge proof (any third party can do this)
3. Equality proof — show "two commitments hide the same value" without revealing the value
C₁:
C₂:
proof.T:
proof.s:
4. 🎯 Range proof (Phase 22b) — prove "0 ≤ v < 2ⁿ" without revealing v
🧩 How it works: decompose v into n bits → Pedersen-commit each bit → prove each bit ∈ {0,1} with a Schnorr OR-proof → an aggregate proof guarantees "sum of bits = original committed value".
🛡️ Why it matters: mathematically rules out negative balances (v < 0 hidden as a two's-complement field element) and overflows (v ≥ 2⁶⁴). The heart of real Confidential Transactions.
📏 Size: O(n). Bulletproofs (inner-product argument) give O(log n), but this is the naive bit-decomposition form: ≈ 7 KB at n=32 and ≈ 14 KB at n=64.
commitment:
proof size:— /
bits:— /
bit OR-proofs:—
🔮 Phase 22d: Shielded UTXO PoolConfidential Transactions — hide amounts from public observers
🔮 Architecture: a shielded ledger that lives alongside the main chain. Only C = V·G + r·H and the range_proof are public for each UTXO. Each transfer is the classic 1 input → 2 outputs (change + payment) UTXO model.
⚖️ Balance equation: the server picks r_recipient = r_input − r_sender as the blinding factor, so C_in − C_out_s − C_out_r = identity holds automatically. Anyone can verify balance consistency with simple addition.
🛡️ Range proof: attaching a 64-bit range proof to both outputs mathematically rules out negative-change fraud (faking V_in − X < 0 as a field element).
⚠️ Honest disclosure of limits: the server still sees the real amount in this phase (a demo-grade trust model). True zero-trust CT needs browser-side ristretto + ECDH. This phase implements "hide from public observers" — same school of thought as Zcash z-addresses or Mimblewimble.
🎁 How to use: press "Faucet" once per account to receive 1,000,000 shielded base units, then try a transfer. The public view confirms amounts are hidden.
1. Join the shielded pool (faucet)
2. Confidential transfer
3. My UTXOs (owner view)
Pick an account and refresh.
4. Public view (amounts hidden)
Press the button to fetch.
5. Confidential transfer log + third-party verification
Press the button to fetch.
🌌 Phase 22e/f/g: Zero-Trust Shielded Poolinit (e) + transfer (f) + encrypted memo (g) — the server never sees V or r
🌌 Trust model: in Phase 22d the server saw the real value V and the blinding r. Here, only the browser knows r — Pedersen commitments and Schnorr H-basis proofs are generated entirely in the browser.
🧮 Math: with V_fixed = 1,000,000 (the faucet constant) we build C = V_fixed·G + r·H and set D = C − V_fixed·G = r·H. We then prove "I know r such that D = r·H" with a Schnorr H-basis proof.
🔭 Why no range_proof here: V_fixed is a public constant, so "v ≥ 0" needs no separate proof. General transfers require range_proof — implemented from Phase 22f onward.
💾 Where r is stored: r lives in your browser's localStorage (key yuu_zt_memo). The server never learns r, so losing the browser means losing both the true amount and the blinding (same self-custody model as Zcash / Monero).
📚 Libraries:@noble/curves loaded via CDN for ristretto255. SHA-512 and randomness via Web Crypto API.
📚 Crypto module: loading…
🔑 Phase 22g: Encrypted Memo — each wallet gets a Ristretto view key. (V, r) is encrypted to the recipient's view public key and stored on chain. From any device with the view secret, your own UTXOs can be decrypted even without localStorage. Same idea as Zcash enc_ciphertext.
🔑 View key state: checking…
1. ZT faucet — mint 1,000,000 units (server learns neither V nor r)
2. My ZT UTXOs (browser decrypts r locally to show the amount)
Pick an account and refresh
3. Public view (V and r are fully hidden; claimed_amount is the faucet constant)
Press the button to fetch.
4. Third-party verification — confirm purely from math, don't trust the server
In the list from step 3, click "✅ Verify" on each UTXO. For init UTXOs this re-runs schnorr_h_basis_verify; for transfer outputs it re-runs verify_range.
🚀 Phase 22f: Zero-Trust Transfer (range_proof × 2 in the browser)
🚀 True confidential transfer: the sender's browser pulls V_in and r_in from the input UTXO, then encrypts both the send amount X and the change V_in − X as Pedersen commitments + 64-bit range_proofs. The server validates value transfer purely from the balance equation + 2 range_proofs without decrypting anything.
⏱ Latency: producing the two range_proofs (64 OR-proofs + aggregation each) in the browser takes ~10–30 seconds. @noble/curves + WebAssembly do the heavy lifting.
🎁 Setup: the sender needs at least one ZT UTXO already in localStorage (run ZT mint first). The recipient just needs a registered wallet. To inspect the received UTXO's amount you also need the sender's localStorage, so creating both wallets in the same browser is the easiest demo.
5. ZT transfer (range_proof × 2 in browser; V/r hidden from server)
🪐 Phase 22h: Multi-IO Zero-Trust Transfer (N inputs → M outputs)
🪐 Ultimate flexibility: combine any number of your UTXOs (up to 16) and split into any number of outputs (up to 16). Send + change in one transaction, batch payments to multiple recipients, splitting and merging UTXOs at will.
🧮 Math: r-correction forces Σ C_in − Σ C_out = identity. Each output carries its own 64-bit range_proof, guaranteeing every output ≥ 0. Balance + range×M makes value creation, destruction, and negative amounts mathematically impossible.
⏱ Latency: proportional to M outputs. M=2 → 10–30s, M=4 → 20–60s, M=8 → 40–120s. Each output runs 64 OR-proofs + aggregation.
🔐 Memo: each output carries its own encrypted memo, individually encrypted to the corresponding recipient's view key.
7. Multi-IO transfer (N inputs → M outputs)
Input ZT UTXOs (owned + unspent + r known) — tick to select
Pick a sender first.
Selected total: 0
Outputs (M rows) — pick recipient and amount
Output total: 0 / ⚠️ Does not match input total
8. Multi-IO transfer log + verification (balance + range_proof × M)
Press the button to fetch.
🌉 Phase 22i: Shielded ↔ Plaintext BridgeTwo-way lobby between visible balances and the hidden shielded pool
🌉 UX revolution: connect "visible bridge balance" and "ZT shielded pool" via deposit (hide) and withdraw (cash out). Day-to-day use the visible balance; switch to the shielded pool only when you need privacy — same playbook as Zcash.
🔬 Information flow: V is briefly disclosed to the server during deposit (necessary to subtract from the plaintext side). Subsequent ZT transfers re-hide V. Withdraw also discloses V and r. The ZT operations between (init/transfer) remain zero-trust.
⚠️ Demo simplification: the bridge balance is a sub-ledger separate from the on-chain plaintext balance (to keep chain integrity intact). A production deployment would merge them.
B1. Bridge balance dashboard
B2. Deposit (plain → shielded) — move bridge balance into the shielded pool
B3. Withdraw (shielded → plain) — convert a shielded UTXO to plain balance
🌳 Phase 25: Merkle Anchor + Nullifier SetMathematical fingerprint of all shielded assets + proof of no double-spend
🌳 Merkle root: a SHA-256 binary tree (depth 16) over every ZT UTXO commitment — a single fingerprint for the entire shielded pool. Any tamper changes the root, so mirror nodes and third parties can verify whole-chain integrity in 32 bytes.
🔒 Nullifier:nf = SHA256("yuu/nullifier/v1" || utxo_id || owner_pubkey). The server computes nf on every spend and adds it to a set — the moment the same nf reappears, the spend is rejected. A mathematical "used" marking that goes beyond a simple spent flag.
🔮 Phase 25b reached:Anonymous Burn via Sigma DLEQ OR-proof. Even when burning one UTXO inside a ring (N = 2–16), the server can never tell which UTXO is the real one (uniform anonymity 1/N). See panel M4 below.
🪐 Phase 25c reached:Anonymous Spend with Balance (Ring-CT). Monero-grade anonymous transfer: pseudo-input commitment + N-way 3-element OR-proof + Σ output range proofs hide who paid whom how much while making value creation mathematically impossible. See panel M5 below.
M1. Current Merkle root + anchor history
M2. Independently verify your UTXO Merkle paths in the browser
M3. Nullifier set (mathematical marker for spent UTXOs)
M4. 🔮 Phase 25b: DLEQ Ring Anonymous Burn
Mix your own UTXO into a ring of N UTXOs
and use a Sigma OR-proof to prove only that "somebody in the ring burned".
The server can never identify which UTXO is the real one.
Anonymity = 1/N (uniform).
M5. 🪐 Phase 25c: Anonymous Spend with Balance (Ring-CT)
Monero Ring-CT–grade anonymous transfer.
Secretly spend one UTXO from a ring of N → distribute to M (≤ 4) hidden outputs. (a) the real input UTXO, (b) the amount V, (c) the blinding r, (d) the change — all of these stay hidden from the server forever.
Mathematically: C'_in − Σ C_out = 0 + range proof per output + N-way 3-element OR-proof.
👻 Phase 27: Stealth Address PoolEven the recipient's account name never appears on chain. Monero/CryptoNote-grade untraceability.
👻 How it works: each wallet has two Ristretto keys — view (a, A=a·G) and spend (b, B=b·G). To send, the sender computes R = r·G, S = r·A, t = H_s(S), X = t·G + B and writes only (R, X) to chain. The recipient's name never appears.
🔍 Reception: every wallet scans every stealth UTXO. It computes a·R → same t → checks X' = t·G + B. Only the matching UTXOs are "for me". The server can never tell whose UTXO it is.
🔥 Spending: derive the one-time spend key x = t + b, compute nf = x · H_id(X), build a DLEQ proof for X = x·G AND nf = x·H_id(X) → the server only learns "someone legitimately claimed this".
S1. Public stealth address (A, B) registry
S2. Stealth send (recipient name never goes on chain)
S3. Scan for UTXOs addressed to me + burn
S4. Public stealth pool + log
🛡️ Phase 22c: Proof of SolvencyProve "my balance is ≥ N" without revealing the balance
📖 Recipe: commit balance + diff with Pedersen → range-proof the diff → tie the two commits together with a Schnorr H-basis equality proof → owner Ed25519-signs the whole bundle. Same construction exchanges use for "Proof of Reserves".
🔢 Math:C_balance = balance·G + r_b·H, C_diff = (balance−N)·G + r_d·H, D := C_balance − N·G − C_diff = (r_b−r_d)·H proven via Schnorr. The range proof guarantees diff ≥ 0.
🪪 Why the signature: canonical bytes (nonce + timestamp + claim_min) are Ed25519-signed by the owner. No replay; the server cannot issue a disclosure without the owner's explicit consent.
⚠️ Limitations (stated honestly): the server already knows the real balance, so it is not hidden from the server. True Confidential Transactions (committing the balance itself) requires a future overhaul. This phase covers "disclosure to external auditors / third parties" via ZKP.
1. Issue a disclosure (owner only)
2. Disclosure log + independent verification
⚡ Phase 8 + 8b: Speed-of-sound justice & true immutable performance"Never verify the same thing twice" + "Re-verify only deltas"
📖 Phase 8 in-memory cache:verify_chain results are cached in memory with (chain_len, 50ms TTL). Even bursty UI requests recompute at most once.
⚡ Phase 8 Lua atomic_append: what used to need WATCH + MULTI + EXEC (2 round-trips) is compressed into 1 round-trip by a Lua script running inside Redis. On tip_hash mismatch, an immediate CHAIN_CHANGED error reports the optimistic-lock failure.
💾 Phase 8b persistent checkpoint: verified ChainState is persisted to Valkey as chain:checkpoint. Across restarts, verify processes only delta blocks. Even at 100M blocks, verification stays O(delta) and finishes in microseconds.
🔒 Safety: if the checkpoint's tip_hash does not match chain[height-1], it is dropped and a full re-verify runs. We never trust the checkpoint more than we trust the chain itself.
🛡️ Availability: on Redis where Lua scripting is disabled, falls back to MULTI/EXEC automatically. Checkpoint save failures are best-effort and never block.
Cache hit rate
—
0 hit / 0 miss
Most recent verify
—
re-processed 0 delta blocks
Lua atomic_append
0
⚠️ Conflicts: 0 / Fallback: 0
Current cache
—
chain_len and age
💾 Checkpoint hit rate
—
0 hit / 0 miss / 0 stale
💾 Checkpoint height
—
last persisted block
💾 Total saves
0
times persisted to Valkey
📉 Cumulative delta
—
total blocks re-processed via incremental verify
⚡⚡ Phase 26: Atomic Lua Spend — shielded commits collapsed into a single 1-RTT Redis call
The commit phase of anonymous burn / stealth burn / anonymous transfer (nullifier SADD + log RPUSH + LTRIM + UTXO SET) used to take 3–4 round-trips between Rust and Redis. Now it is compressed into a single EVALSHA Lua call. Race conditions are physically zero because everything runs atomically inside Redis. Double-spends are rejected instantly with NF_EXISTS — no chance to slip through.
⚡⚡ Lua success rate
—
success / (success + conflict) — closer to 100% means Lua dominates
🔮 anon_burn commit
0
⚠️ NF_EXISTS rejected: 0
👻 stealth_burn commit
0
⚠️ NF_EXISTS rejected: 0
🪐 anon_transfer log commit
0
tx + burn logs combined into 1 RTT
🔁 NOSCRIPT reloads
0
self-heals after a Redis restart
📜 Lua script load state
commit_nullifier: ⏳
commit_stealth_burn: ⏳
commit_anon_transfer_logs: ⏳
scripts are SCRIPT LOAD'd at boot and their SHA1 is cached
🏛️ Final Phase: Rust Transfer SystemIntegration and 10 quadrillion stress test — "Don't trust, compute. The computation was perfect."
Completion declaration:/final/status certifies that Phase 1 through Phase 27 all run concurrently on this server. The response includes fortress_seal_hex, a SHA-256 fingerprint of the whole snapshot; anyone can recompute canonical bytes to verify integrity.
Stress test: pound the atomic Lua commit path (Phase 26) with N concurrent workers and measure throughput / P50/P95/P99 latency / integrity in one shot. The identity succeeded == nf_set delta is the mathematical proof that Lua atomicity holds under load.
🏆 27-phase completion checklist
📊 Fortress snapshot (/final/status)
🏛️ phases completed
—
/27
⛓️ chain length
—
epoch — / fenced —
👥 registry
—
view keys: — / stealth: —
🛡️ Shielded ZT
—
merkle leaves: —
🔮 Nullifier set
—
stealth nf: —
👻 Stealth UTXO
—
recipient name remains unknown forever
⚡⚡ Lua loaded
—
completeness —
🔏 fortress_seal_hex (SHA-256 of canonical snapshot)
—
if this hex matches, state is identical — tamper-evident seal
🚀 Phase 26 Lua-path synthetic stress test
Hammer the COMMIT_NULLIFIER Lua script with N synthetic nullifiers in parallel. This isolates the 1-RTT commit path — no crypto, no ZKP — so the latency you see is the physical floor Phase 26 reached.
ops/sec
—
—
latency P50 / P95 / P99
—
µs (mean: — / max: —)
succeeded / conflict / err
—
total — × conc —
🔐 integrity
—
succeeded == nf_set delta ⇔ zero loss / zero duplication
🗼 Watchtower Service(Phase 19 reward economy)"Math is awake so you can sleep"
📖 How it works: a third-party wallet keeps the latest channel state in localStorage. If it detects a fraudulent close with stale state, it auto-submits a counter-proposal.
🔐 Least authority: Watchtowers cannot steal funds. They may only submit "a newer seq", and that mathematically resolves to the correct allocation.
💰 Phase 19 carrot: if tower and bounty are written into the channel state at open time, payment is auto-released to a successful defender only. The numbers are pre-signed by both parties — no arbitrary increase or decrease is possible.
⚔️ Phase 21 stick: when a Watchtower submits a counter-proposal with slash_bond, getting overwritten by a newer seq transfers the bond to the new submitter (slashing). Bringing stale information costs you — game theory makes only the freshest submitter rational.
⚡ Use case: mobile-only channel users can run a Watchtower on their PC to handle disputes while they are away. Reservations turn this into an economy where Watchtowers worldwide want to protect you.
🛠️ Under the hood: if a pending close exists, the server accepts a counter-proposal from any sender. Bounty is paid automatically only when latest_initiator == watchtower_addr. slash_bond is not part of the signed state message — both parties' prior signatures stay valid (the V3 format is the submitter's standalone declaration).
Channels watched
0
open channels in localStorage
Interventions
0
counter-proposals submitted
Latest scan
—
auto every 5 seconds
💰 Total bounty earned
—
sum across resolved chan_close events
🗼 Reserved while defending
—
latest-submitter on pending closes
⚔️ Slashing earned
—
total bonds slashed from stale submitters
⚔️ Bond in escrow
—
your own bonds on pending closes
Activity log
idleNothing has happened yet. Enable the Watchtower above.
🔒 HTLC (Hashed Time-Lock Contract)"Reveal the secret to claim; auto-refund when the deadline passes"
When the sender opens an HTLC, the browser generates a random preimage (secret) and only its SHA-256 hash goes on chain.
If the recipient reveals the preimage before the refund deadline, they claim the funds. After the deadline, funds auto-refund to the sender.
This is the same primitive that underpins Bitcoin Lightning Network and atomic swaps.
Mode:
⚡ Payment-route view (same hashlock = 1 route)
Individual HTLCs
💸 TransferInstant / Time-locked / Multi-sig
Signing in browser…
Amount
0
Fee
0
Total debit
0
Recipient credited
Immediate ✨
📋 Managed OrdersOrder → Transfer → Complete lifecycle, atomized in Lua
📋 How it works: "Confirm intake" reserves the transfer amount into a locked balance — Lua atomicity physically prevents double-spend. The "Transfer" button then runs the real /transfer flow and appends to the chain atomically. Failures release the lock and record FAILED. "Cancel" releases the lock and writes CANCELED to the ledger.
🔐 Security: the browser pre-signs an Ed25519 TransferRequest and stores it in the order. Execution goes through the exact same path as /transfer, so signature verification, conservation of value, and balance protections all remain intact.
📥 Confirm intake (create order)
📋 Order list (settlement info)
total: —
No (TXID)
Sender
Receiver
Amount
Created
Settled
State
Block
Action
No orders yet — create one with "Confirm intake" above.
🛡️ Three shields: ① Connectivity control: a "self-fired fence" the operator can trigger explicitly. ② CSV bulk transfer: hundreds of payments committed sequentially-atomic in one click. ③ Face liveness + fingerprint: random action prompts + camera motion detection block the "fingerprint while asleep" attack.
🔐 Mathematical basis: WebAuthn platform authenticators keep secret keys inside the hardware Secure Enclave; liveness uses the SAD (sum of absolute differences) of consecutive camera frames to require "actual motion". Stacked in series, the attacker must produce a fingerprint AND a conscious, moving body simultaneously.
🔌 Connectivity (Operator-controlled fence)
🟢 CONNECTED
manual_lock
—
fenced
—
write_allowed
—
mode / epoch
—
peer count
—
🔐 Biometric guard (fingerprint + face liveness)
⚠️ Face liveness needs camera permission. A random instruction appears: "Turn right" / "Turn left" / "Look up" / "Open mouth" / "Blink 3 times". During a 4-second observation window, the SAD (sum of pixel-level differences) between consecutive camera frames must exceed a threshold to pass. A sleeping face produces almost no motion, so this fails.
📦 CSV bulk transfer
Template: sender,receiver,amount (line 1 = header, line 2+ = payment instructions). Each row is initiated + executed individually as a Phase 28 order.