Files

Siavash Sameni 0060b16912 docs: ship in-house RN checkout, scope 5 follow-up tasks (#7-11)

In-house Request Network checkout went fully end-to-end on dev today.
A real 0.01 USDC payment flowed through wallet connect -> approve ->
ERC20FeeProxy.transferFromWithReferenceAndFee -> RN webhook ->
TransactionSafetyProvider -> Payment.status=completed -> page success
state. Tx 0x494c77a29161b5100d8e0b1ac675f1822955d0bb3633ecdbfafb886f84f2f320.

Docs:
- New PRD: Wallet, Multichain, Confirmations, AML, Trezor
  (5 follow-ups, each sized for an independent contributor)
- Updated PRD: Request Network In-House Checkout (phases 0..3 done,
  phase 4 partial, phases 5-6 not started)
- Updated handoff: deployed versions, what is working end-to-end,
  follow-up tasks index

Taskmaster: 5 new top-level tasks (#7..#11) covering ephemeral
destination wallets, multichain proxy registry + USDC/USDT, runtime
confirmation thresholds, optional seller-paid AML screening, and
Trezor signing for admin actions. Tasks are scoped fine-grained so
each is independent enough for kimi to pick up.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

2026-05-28 15:50:24 +04:00

1.2 KiB

Raw Blame History

taskmaster_id, status, priority, depends_on, parent_id, source, generated_at

taskmaster_id

status

priority

depends_on

parent_id

source

generated_at

4.3

done

high

taskmaster

2026-05-28T11:49:27.076Z

4.3 - Specify funds ledger and escrow state machine

4.3 - Specify funds ledger and escrow state machine #taskmaster #priority/high #status/done ⏫ 🆔 tm-4-3 ⛔ tm-2

Metadata

Field	Value
Taskmaster ID	4.3
Status	done
Priority	high
Dependencies	2
Parent	4 - Define backend security and refactor strategy from latest audit

Description

Define canonical money movement and legal state transitions before refactor or provider migration.

Details

Create specs for FundsAccount, LedgerEntry, FundsBalance, gross paid, provider fees, platform fees, held, disputed, releasable, released, refunded, idempotency keys, reconciliation behavior, purchase request states, payment states, escrow/funds states, dispute states, valid transitions, forbidden transitions, and release/refund/admin override preconditions.

Verification

Spec can be used to reject double-release, release-during-dispute, underfunded payout, and ambiguous provider-event scenarios.

1.2 KiB Raw Blame History