Skip to content

fix(platform-wallet): classify asset locks funding foreign credits as outgoing - #5787

Draft
Claudius-Maginificent wants to merge 4 commits into
feat/sqlite-wallet-restorefrom
fix/asset-lock-credit-direction
Draft

Claudius-Maginificent wants to merge 4 commits into
feat/sqlite-wallet-restorefrom
fix/asset-lock-credit-direction

Conversation

@Claudius-Maginificent

Copy link
Copy Markdown
Collaborator

TL;DR

What this does: Shows an asset lock as a payment when it funds someone else's Platform credits, instead of as a transfer within the wallet.

Value: Wallet history no longer labels money sent to another party as moving between the wallet's own accounts.

Risks: Work in progress. The amount shown is already correct; only the direction label changes. No consensus change.

Issue being fixed or feature implemented

Follow-up to #5150, addressing its review threads on asset-lock direction (CodeRabbit, thepastaclaw).

As a wallet user, I want an asset lock that pays another party's Platform credits to appear as outgoing, so my history does not present it as a self-transfer.

Actual behavior

An asset lock spending the wallet's coins, with no ordinary output leaving the wallet, is labelled Internal even when its credit outputs pay keys the wallet does not own. The wallet's own builder never produces this shape; it requires an externally built transaction signed with the wallet's keys.

Expected behavior

The lock is Internal only when the wallet owns every credit output; otherwise it is Outgoing.

What was done?

Work in progress. Planned:

How Has This Been Tested?

Pending — foreign-credit regression tests for live accounting and SQLite repair.

Breaking Changes

None expected. To be confirmed once the public wallet_direction/wallet_accounting signatures settle.

Checklist:

  • I have performed a self-review of my own code
  • My Rust, FFI, WASM, Swift or Kotlin changes follow the coding conventions
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
  • I have made corresponding changes to the documentation if needed

🤖 Generated with Claude Code

🤖 Co-authored by Claudius the Magnificent AI Agent

Skeleton commit for the follow-up to #5150 that classifies asset locks
funding foreign Platform credit outputs as outgoing.

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

coderabbitai Bot commented Nov 6, 2026

Copy link
Copy Markdown
Contributor

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

@thepastaclaw

thepastaclaw commented Nov 6, 2026 •

Copy link
Copy Markdown
Collaborator

🕓 Review not started yet because this PR is a draft.

  • Request normal review — click when the PR is ready for review.
  • Request priority review — click to move this review to the front of the queue.

Commit df0c158. Normal review starts when eligible; priority review starts as soon as a slot is available.

lklimek and others added 3 commits November 6, 2026 10:28
…eys as outgoing

`wallet_direction` called every asset lock that spends wallet inputs and
pays no external ordinary output `Internal`, without looking at the
payload's credit outputs. A lock whose credits pay keys the wallet does
not own moves value out of the wallet and is now `Outgoing`; it is
`Internal` only when every credit pays a key of one of the wallet's own
(non-contact) accounts. The net amount is unchanged.

The decision stays in one place: `wallet_accounting` takes the owned
credit scripts and both callers supply them from wallet knowledge.

- Live projection: the wallet's in-memory address pools, read under the
  same guard as the projected slices.
- SQLite repair: the persisted `core_address_pool` rows. The live
  projection emits the owning keys (unused ones as `addresses_derived`,
  used ones as `addresses_marked_used`), and the store inserts their pool
  rows before the record and its repair, never rewriting a stored row.
  A credit key the wallet derived past its persisted snapshot therefore
  cannot make the repair read the wallet's own lock as `Outgoing`.

`asset_lock_credit_outputs` is the shared accessor for the payload's
credit outputs. `test_support::fold_wallet_records` takes the owned
credit scripts.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…e live and SQLite paths

- Emit a credit key as a derived address only while it is `Available`.
  Hosts store a derived entry as unused, so a reserved key sent that way
  lost its reservation; used and reserved keys now go out as marked-used
  entries carrying their state.
- Count a credit as owned live only when its key is emitted as evidence,
  so an available key with no ECDSA public key is not claimed by the live
  projection while the SQLite repair cannot see it.
- Exclude `platform_payment` pool rows from the repair's ownership set:
  the live projection reads key-wallet's `all_accounts()`, which holds no
  PlatformPayment pools.
- Skip, with a warning, a credit-key evidence row that contradicts stored
  key material instead of failing the whole Core write; pool snapshots
  still fail on a conflict.
- Point the `wallet_direction` docs at the Swift mirror in #5417 rather
  than a Swift function this branch does not have.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Swift's history reconciliation in #5417 calls the Rust rule rather than
reimplementing it.

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

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants