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.3 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

5.5

done

high

taskmaster

2026-05-28T11:49:27.076Z

5.5 - Add Telegram payment and wallet strategy

5.5 - Add Telegram payment and wallet strategy #taskmaster #priority/high #status/done ⏫ 🆔 tm-5-5 ⛔ tm-2 ⛔ tm-4

Metadata

Field	Value
Taskmaster ID	5.5
Status	done
Priority	high
Dependencies	2, 4
Parent	5 - Deliver Telegram-native app, bot, and wallet experience

Description

Evaluate and implement safe payment entry points for Telegram-native users without weakening escrow accounting.

Details

Compare Bot API payments/Stars, Wallet Pay, TON Pay, TON Connect, Request Network links, and existing crypto checkout. Select a first payment path and document rejected options. Store provider, Telegram user ID, deep-link source, payment reference, invoice/order/request ID, currency, amount, expiration, and idempotency key. Wallet/TON flows must validate recipient, asset, amount, memo/reference, confirmation status, and reconciliation evidence before crediting escrow. Refund/release behavior must remain compatible with canonical ledger and dispute holds.

Verification

See Telegram-native PRD acceptance criteria.

1.3 KiB Raw Blame History