[ovitrif]

Twin: synonymdev/bitkit-ios#1179

Description

• Replaces the 3D Tether image (tether_coin.png) with the updated render from Figma, which fixes the brand mark's accuracy. It shows on the USDT intro sheet, the USDT wallet header and the USDT network pickers.
• Places that image as the Figma Visual component does: 256 dp square, 32 dp down inside its 256 dp box. The old 304.76 × 228.57 crop was tuned to the old render's padding and would draw the new render about 20% too large.
  • On the USDT wallet header this moves the coin about 30 dp down, to where the Wallet USDT frame draws it: the same Visual component, flipped.
• Adds "quickly" to the USDT intro description, in English and every locale: "Enable USDT (Tether) to quickly send and receive digital dollars with Bitkit."
• Colours send reviews by the paying rail on every send flow, as in the Payment Request frames: lightning purple with the bolt icon, onchain orange with the speed icon, USDT teal with the $ icon.
  • While a payment request prepares, its colour follows the rail it accepts, not the last send's wallet: lightning-only purple, onchain-only orange, USDT teal, and neutral when it accepts both bitcoin rails.
• Always shows Request Payment on Subscriptions › Payments. With no profile, or once contacts have loaded and are empty, it opens Add Contact, through the same route as the Contacts intro: the Add Contact sheet when signed in, otherwise profile setup first. Otherwise it opens the recipient picker, which says when none of them can receive a request.

Out of Scope

• Recipient picker: no loading state while eligibility loads — bug: recipient picker says no contact can receive while loading #1742, raised in fix: apply design nits #1741 (comment).
• Shop: the new Market and Services suggestion cards (design comment). They need new artwork, two new gradients, four new strings in every locale, and decisions on where Services goes when Paykit is off and whether Market opens in-app or in the browser.

Design

Bitkit - Handoff v63:

• New: USDT (image and copy; design comment)
• Wallet USDT (funds & activity)
• USDT Network
• Send (Pay Payment Request): lightning, onchain, USDT (design comment)
• Subscriptions › Payments (design comment)

Preview

Figma (left) and this PR on an emulator (right):

Intro	Wallet	Network	Payments

Recordings (2x):

USDT intro, wallet, network pickers	Request Payment with no contacts
android-flow2x.mp4	android-request2x.mp4

QA Notes

Setup

For J1's contact steps: create a Pubky profile in the app on two devices (staging homeserver), then add each other through Add Contact.
Dev debug build on regtest with the default USDT endpoints, fresh wallet with Paykit on and no contacts.

Journeys

• J1: new request-payment-without-contacts.xml — Request Payment shows with no contacts and opens Add Contact; with contacts it opens the recipient picker

Manual Tests

• 1. Open a Paykit payment request while it prepares → lightning-only purple, onchain-only orange, neutral when it accepts both — needs a linked Paykit contact sending a request

Automated Checks

• updated PaymentRequestsScreenTest.kt — drops the case that expected no button without eligible contacts
• updated SubscriptionsScreenTest.kt — follows the removed canRequestPayment parameter

Evidence

• On 75b3b6c, dev debug build, Android 16 emulator: the intro sheet, USDT wallet header, send network picker and receive network picker show the new render at the Figma size (pentagon ≈193 dp wide, flush 32 dp above the intro headline), and the intro shows the new copy.
• On 569137b: J1 passes in full on a device, with two profiles linked as private Paykit contacts: no profile opens profile setup; signed in with no contacts opens the Add Contact sheet; with a saved contact the recipient picker lists it (QA).
• On b9a24db: manual test 1 passes for every rail, staged with a local debug-only hook (QA).
• just lint and just test pass; app and instrumented tests compile.

Gaps

• UsdtDepositReceiveScreen.kt also shows the Tether image and was not opened; it uses the same composable.

Models used

• Planning/scoping: claude-opus-5-5 (reasoning: Not exposed)
• Implementation: claude-opus-5-5 (reasoning: Not exposed)
• Review: Not performed

The session metadata does not expose the reasoning setting.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-30T21:21:36.597181Z	75b3b6c	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 75b3b6c5e5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[greptile-apps]

Confidence Score: 5/5

[Low impact] The PR appears safe to merge based on the code reviewed.

Summary

Updates the shared USDT illustration and adds “quickly” to the English intro.

• USDT screens show the updated Tether artwork at its Figma size.
• The USDT intro description now includes “quickly.”

_{Reviews (1) · Last reviewed commit: "fix: update tether icon and usdt copy" · Reviewed by Greptile}

[talosmachina]

No findings. Swaps the 3D Tether render, redraws UsdtCoinIllustration as a 256 dp fit image drawn 32 dp down, and adds "quickly" to the English intro copy. Reviewed 5dc7a99, full tier, static: per the review policy for this repo the branch was not built here, so this rests on the code and CI.

What I checked, and 3 candidates I ruled out

Read in full: UsdtWalletScreen.kt, UsdtIntroSheet.kt, UsdtNetworkPicker.kt, UsdtDepositReceiveScreen.kt (NetworkSelector), strings.xml hunk
Call sites traced: all four UsdtCoinIllustration callers; the removed requiredSize and ContentScale imports have no other use in the file
Asset: new tether_coin.png is 1024x1024 with its opaque bounds at 771x721+125+174, so at 256 dp the art ends about 32 dp above the box bottom; the offset(y = 32.dp) puts it flush with the layout bottom
CI: lint, build and build-local were still pending at review time

Ruled out

• Drawn image overlapping the next element (NetworkSelector puts state.error text right after the illustration): offset does not change layout size, but the 32 dp it pushes past the bounds is the PNG's transparent bottom margin, so nothing opaque overlaps.
• Wallet header shift: the extra 32 dp also applies at the TopEnd call site; the PR's wallet screenshot against Figma covers that placement, and it is the same on the iOS twin.
• Translations not updated: the other locales keep the old wording, which is still accurate copy, and the PR scopes it out explicitly.

Merge confidence: 4/5, no findings, but CI had not finished and the branch was not built here.

Reviewer model: claude-opus-5-5
Reasoning effort: Not exposed (the review session's metadata does not report it)

[github-actions]

Regtest APK

Built from 569137b (run).

Download bitkit-dev-debug universal APK (expires in 30 days).

[coreyphillips]

Two independent reviews.

worth doing, does not block

• Translations of usdt__intro_description keep the old wording (app/src/main/res/values/strings.xml:1240)

the reviewers disagree, your call

• Wallet header coin moves about 30 dp lower, but the description says unchanged (app/src/main/java/to/bitkit/ui/screens/wallets/usdt/UsdtWalletScreen.kt:330-334). Objection: The artwork does move roughly 30 dp downward, but that alone does not establish incorrect placement. The PR description was unavailable, so I could not independently confirm the claimed wording mismatch. Answer: The PR body's Out of Scope section says "UsdtWalletScreen.kt: the header illustration's screen position is unchanged." From the alpha bounds, the old crop put the pentagon's top at about 45 dp inside the 256 dp box (old rows 228..804 of 1000, scaled 0.3048, cropped and centred). The new render's top is at 43.5 dp plus the 32 dp offset, about 75.5 dp, so at the call site (statusBars + 4 dp, lines 330-334) the visible coin moves about 30 dp down and its bottom about 35 dp. The code may well match Figma; the fix is to correct that line of the description so reviewers of the Wallet screen expect the move.

[ovitrif]

Pushed 0a60ec4, which adds Aldert's other design nits as separate commits (title now fix: apply design nits):

• 045ec2e: every locale gets the equivalent of "quickly" in the USDT intro, per the repo rule.
• 88504a1: send reviews keep the paying rail's colour while a payment request prepares, instead of grey.
• 82788cb: Request Payment always shows on Subscriptions › Payments and opens Add Contact when no contact can receive a request.

The description, Preview and QA Notes match the new head. The Shop Market and Services cards stay out of scope; the description says why.

[ovitrif]

Wallet header coin moves about 30 dp lower, but the description says unchanged

@coreyphillips The move is intended: the Wallet USDT frame draws the header coin with the same Visual component (flipped), so the shared 32 dp offset puts it where Figma has it. The description now says so instead of "unchanged". The other new commits since your review are listed in the comment above.

[ovitrif]

QA on 0a60ec4

Dev debug build, Android 16 emulator. The preparing state was staged with a local debug-only hook that opens the real SendConfirmContent with a preparing request; the hook is not part of this PR.

• 1. Payment request while it prepares: lightning shows the purple swipe and FROM/FOR icons, onchain the orange ones; no grey state.
• J1 (request-payment-without-contacts.xml), on 82788cb: Request Payment shows on the empty Payments tab; with no profile it opens profile setup, the step before Add Contact.

The USDT review is unchanged here: it already had the teal swipe and $ icon.

android-preparing2x.mp4

[coreyphillips]

Rechecked after 4 new commits (045ec2e, 88504a1, 82788cb, 0a60ec4). Nothing blocking remains.

addressed

• Translations of usdt__intro_description keep the old wording (app/src/main/res/values/strings.xml:1240). Fixed: 045ec2e updates usdt__intro_description in all 15 values-*/strings.xml files ("schnell", "rapidement", "rápidamente", "быстро" and so on). I grepped each locale file at HEAD to confirm. values-night and values-v31 have no string resources, so none are missing.
• Wallet header coin moves about 30 dp lower, but the description says unchanged (app/src/main/java/to/bitkit/ui/screens/wallets/usdt/UsdtWalletScreen.kt:330-334). Fixed: The point was the description's wording, not the code. The description no longer says "unchanged". It now says the wallet header coin moves about 30 dp down, to where the Wallet USDT frame draws it. UsdtWalletScreen.kt and UsdtCoinIllustration are untouched since 5dc7a99 (checked with git diff 5dc7a99..HEAD), so the corrected text matches the code.

new since the last review

worth doing, does not block

• Preparing request tint comes from the previous send's payMethod (app/src/main/java/to/bitkit/ui/screens/wallets/send/SendConfirmScreen.kt:370-375)
• Request Payment opens Add Contact while recipients are still loading (app/src/main/java/to/bitkit/ui/screens/paymentrequests/PaymentRequestsScreen.kt:224)
• Lightning requests prepare with onchain colours (app/src/main/java/to/bitkit/ui/screens/wallets/send/SendConfirmScreen.kt:370-374)

[ovitrif]

QA on b9a24db

Pushed 90596b5, 79774b1 and b9a24db, answering @ben-kaufman's and @coreyphillips's new threads:

• 90596b5: when no target is eligible yet but saved contacts exist, Request Payment refreshes eligibility before routing, so Add Contact opens only once eligibility is known to be empty.
• 79774b1: while a request prepares, the colour comes from the request's accepted methods, not the stale payMethod: lightning-only purple, onchain-only orange, USDT teal, neutral when it accepts both bitcoin rails.
• b9a24db: the journeys README lists the Request Payment identifier pair.

Dev debug build, Android 16 emulator. The preparing state was staged with a local debug-only hook (not part of this PR) using the default SendUiState(), whose payMethod is onchain:

• 1. Preparing request: lightning-only purple, onchain-only orange, mixed neutral.
• J1 (request-payment-without-contacts.xml): with no contacts, Request Payment opens profile setup, the step before Add Contact.

Preparing request	J1
android-preparing22x.mp4	android-j12x.mp4

just lint and just test pass on the head.

[coreyphillips]

Rechecked after 3 new commits (90596b5, 79774b1, b9a24db). Nothing blocking remains.

addressed

• Preparing request tint comes from the previous send's payMethod (app/src/main/java/to/bitkit/ui/screens/wallets/send/SendConfirmScreen.kt:370-375). Fixed: SendConfirmScreen.kt:371-375 now takes the colour from preparingRequest.preparingAccentColor() (lines 990-1001) whenever a request is preparing, so uiState.payMethod no longer decides it. I read the helper: Bolt11/Lnurl-only gives purple, onchain-only orange, USDT-only teal, and mixed or unknown rails give White64. That colour feeds the summary icons (466) and the swipe (522).
• Lightning requests prepare with onchain colours (app/src/main/java/to/bitkit/ui/screens/wallets/send/SendConfirmScreen.kt:370-374). Fixed: Same change as point 1. A request accepting only btc-lightning-bolt11 maps to MethodId.Bolt11, so preparingAccentColor() (SendConfirmScreen.kt:990-1001) returns Colors.Purple whatever payMethod the fresh SendUiState() from SendSheet holds. I confirmed it by reading the when branches against the MethodId raw values in PublicPaykitRepo.kt:675-682.

still open

• Request Payment opens Add Contact while recipients are still loading (app/src/main/java/to/bitkit/ui/screens/paymentrequests/PaymentRequestsScreen.kt:224). PaymentRequestsScreen sends the button to onAddContact whenever eligiblePaymentRequestTargets is empty (PaymentRequestsScreen.kt:224). That list starts as emptyList() (PaykitPaymentRequestRepo.kt:389). It is filled only after refreshEligibleTargets reads each saved contact's Paykit endpoints on the bulk lane. If the first refresh fails, the failure path filters an already empty list, so it stays empty. So a signed-in user with Paykit-capable contacts who opens Subscriptions › Payments soon after launch, or while offline, is sent to Contacts with the Add Contact sheet open. They should get the recipient picker. Before this change the button was hidden in that window. Now it is shown and goes to the wrong place. The screen cannot tell "not loaded yet" from "no eligible contacts". One fix: route to Add Contact only when pubkyContacts is empty. If there are contacts, open ReceiveRoute.PaymentRequestRecipient, or wait for the first discovery to finish. Found by reading the code; not reproduced on a device. The loading window is covered when the refresh succeeds. canRequestPayment (AppViewModel.kt:1369-1374) still cannot tell a failed lookup from "no eligible contacts". Offline, each canReceivePaymentRequests fails and eligibleTargets falls back to previousTargets[publicKey], which is empty. A thrown identityStatus, or OperationInProgress from checkRefreshAdmission on Background priority, goes through onFailure and leaves the list empty. In each case the tap opens Add Contact for a user with capable contacts, which is the offline case the point named. refreshEligibleTargets returns Result<Unit> and the discovery's failedPublicKeys are dropped, so the screen has no failure signal to act on.

new since the last review

worth doing, does not block

• Request Payment tap does nothing visible while a forced discovery runs (app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt:1369-1374)

nits

• preparingAccentColor reimplements MethodId.fromRawValue (app/src/main/java/to/bitkit/ui/screens/wallets/send/SendConfirmScreen.kt:990-993)

[ovitrif]

QA on 3e518bf

Pushed 3e518bf, answering @coreyphillips's two new threads:

• Request Payment no longer waits on a forced eligibility refresh. It routes on the saved contacts already on the device: no saved contacts opens Add Contact; otherwise it opens the recipient picker, which updates as eligibility loads and says when no contact can receive a request. AppViewModel.canRequestPayment is gone.
• preparingAccentColor reuses MethodId.fromRawValue.

Dev debug build, Android 16 emulator:

• J1 (request-payment-without-contacts.xml): with no contacts, Request Payment opens profile setup, the step before Add Contact.
• just lint and just test pass.

android-j1b2x.mp4

Manual test 1 (preparing colours) is unchanged in behaviour since 79774b1; its run is in #1741 (comment).

[coreyphillips]

Rechecked after 1 new commit (3e518bf). Nothing blocking remains.

addressed

• Request Payment opens Add Contact while recipients are still loading (app/src/main/java/to/bitkit/ui/screens/paymentrequests/PaymentRequestsScreen.kt:224). Fixed: PaymentRequestsScreen.kt:222 now routes on contacts.isEmpty(), where contacts is pubkyRepo.contacts. That list comes from the local SDK state (observedContactRecords, PubkyService.kt:222-224), not from endpoint discovery. With saved contacts the tap opens ReceiveRoute.PaymentRequestRecipient (ContentView.kt:942), which is the fix suggested last time. The only window left is before the local contacts read finishes after session restore, which is short.
• Request Payment tap does nothing visible while a forced discovery runs (app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt:1369-1374). Fixed: canRequestPayment is gone from AppViewModel, and a grep of app/src finds no references to it. The click handler at PaymentRequestsScreen.kt:222 now just picks a callback and awaits nothing. Taps no longer wait silently and no longer queue a forced discovery behind targetDiscoveryMutex.
• preparingAccentColor reimplements MethodId.fromRawValue (app/src/main/java/to/bitkit/ui/screens/wallets/send/SendConfirmScreen.kt:990-993). Fixed: SendConfirmScreen.kt:991 now reads acceptedPaymentEndpointIdentifiers.mapNotNull(MethodId::fromRawValue). fromRawValue (PublicPaykitRepo.kt:700-703) compares against rawValueForNetwork(Env.network), the same value the rawValue getter returns, so behaviour is unchanged. Checked by reading the code; I did not compile it here.

new since the last review

worth doing, does not block

• Recipient picker says no contact can receive while targets are still loading (app/src/main/java/to/bitkit/ui/ContentView.kt:940-943)
• J1 does not cover the saved-contacts branch it is listed as proving (journeys/subscriptions/request-payment-without-contacts.xml:1-14)

[ovitrif]

QA on 569137b

Pushed 70eaf45 and 569137b, answering @coreyphillips's two new threads:

• Add Contact opens only with no signed-in profile, or once contacts have loaded and are empty; the changelog fragment now says "when you have no contacts".
• Opening the recipient picker from Request Payment starts a forced eligibility refresh without waiting on it (AppViewModel.showPaymentRequestRecipient, the same pattern as showPaymentRequests), so the list fills sooner after launch. The picker still has no loading state, as before this PR; that is tracked in bug: recipient picker says no contact can receive while loading #1742 (3.2.0).
• J1 gains the saved-contacts steps.

Dev debug build, Android 16 emulator; just lint and just test pass:

• J1 (request-payment-without-contacts.xml), partly run: on a wallet with no profile, Request Payment opens profile setup, the first step before Add Contact. The Add Contact sheet step and the saved-contacts steps were not run: they need a signed-in profile and a second identity with a private connection. Earlier QA comments ticked J1 after only these first steps; this is the accurate status.

android-j1c2x.mp4

[coreyphillips]

Rechecked after 2 new commits (70eaf45, 569137b). Nothing blocking remains.

addressed

• J1 does not cover the saved-contacts branch it is listed as proving (journeys/subscriptions/request-payment-without-contacts.xml:1-14). Fixed: request-payment-without-contacts.xml:13-14 adds the saved-contact steps, and the description now names the second identity they need. The PR body keeps J1 unchecked, and Evidence and Gaps say the Add Contact sheet step and the saved-contact steps were not run, which matches the reported run.

still open

• Recipient picker says no contact can receive while targets are still loading (app/src/main/java/to/bitkit/ui/ContentView.kt:940-943). With saved contacts, Request Payment on Subscriptions › Payments now opens the recipient picker even while eligiblePaymentRequestTargets is still empty. That happens during the first discovery after launch, and after a discovery that failed while offline. The picker has no loading state. When recipients is empty it shows wallet__payment_request_recipient_unavailable (CreatePaymentRequestScreen.kt:664-669): "Payment requests can only be sent to a saved contact with a private connection." A user whose linked contacts can receive is told they cannot, and the list appears later. Opening the picker from ContentView.kt:942 does not start a refresh. showPaymentRequests() and showSubscriptionCreator() (AppViewModel.kt:8141-8149) launch refreshPaymentRequestTargets(force = true) without awaiting it. This path relies on the polling loop's maintenance refresh, every 30 to 60 s and only while online. Before this branch the picker could not be reached from here with empty targets, because the button was hidden. Two fixes that would not reintroduce the old wait: launch the same non-awaited forced refresh when the sheet opens, and show a loading row instead of the unavailable copy until the first discovery completes. Found by reading the code; not reproduced on a device. The non-awaited forced refresh now runs when the picker opens (AppViewModel.kt:8149-8152, wired at ContentView.kt:941). But the picker still opens straight onto the unavailable copy (CreatePaymentRequestScreen.kt:669) until that network discovery finishes, so the window is shorter, not gone. Create Subscription does reach the same content with empty targets, but the claim that Receive did too does not hold: both Receive entries are hidden when targets are empty (ReceiveSheet.kt:175, :288). Deferring the loading row to #1742 is reasonable for a non-blocking point and need not hold the merge, but the code does not settle it yet.

[ovitrif]

QA on 569137b: J1 in full

Dev debug build, Android 16 emulator, regtest dev build against the staging Pubky homeserver. Setup: a new Pubky profile created in the app on each device (Android "QaAndroid", iOS "QaIos"), then each added the other through the normal Add Contact flow, giving a private Paykit connection.

• J1 (request-payment-without-contacts.xml), every step:
  • Signed in with no contacts: Request Payment on the empty Payments tab opens Contacts with the Add Contact sheet.
  • After adding QaIos as a contact from that sheet: Request Payment opens the recipient picker, which lists QaIos.

Signed in, no contacts → Add Contact	Saved contact → recipient picker
android-j1full2x.mp4	android-j1saved2x.mp4

The no-profile branch passed earlier on this head; the send-review colour cases are unchanged since their last run.

[ovitrif]

@coreyphillips Merging this PR on your approval of head 569137b, with a device run of its cases on that head, checks green and no open threads.