Skip to content

Add support for Single Asset Vault deposit-blocking flags/fields - #1341

Open
cybele-ripple wants to merge 2 commits into
mainfrom
single-asset-vault-updates
Open

cybele-ripple wants to merge 2 commits into
mainfrom
single-asset-vault-updates

Conversation

@cybele-ripple

Copy link
Copy Markdown
Contributor

High Level Overview of Change

  • Decode the new Vault ledger flags lsfVaultDepositBlocked and lsfVaultOwnerCanBlockDeposit, and show a "Deposits Allowed" indicator on the Vault page (only rendered when the vault owner has the capability to block deposits).
  • Add new tf* transaction flag entries for VaultCreate (tfVaultOwnerCanBlockDeposit), VaultSet (tfVaultDepositBlock, tfVaultDepositUnblock), and VaultDeposit (tfVaultDonate), plus the universal tfInnerBatchTxn flag, so they decode correctly in the generic transaction Flags display.
  • Render VaultDelete's new MemoData field in both the Simple and Detailed transaction views.
  • Fix long Vault ID / Owner values being truncated on the Vault page, and long Vault IDs being cut off (not wrapping) in the Simple view of VaultClawback, VaultDelete, VaultDeposit, VaultSet, and VaultWithdraw transactions.

Context of Change

Tracks upstream additions to Single Asset Vault deposit blocking (XLS-469, XLS-470, gated behind LendingProtocolV1_1), mirrored in xrpl4j#832. The xrpl npm package doesn't have these fields yet, so access uses as any casts with a comment, matching the existing pattern for fields ahead of the package's types (e.g. CredentialIDs in EscrowFinish/PaymentChannelClaim).

The truncation fixes were found while manually previewing this work — Vault IDs and owner addresses were either shortened unnecessarily or overflowing instead of wrapping, despite there being enough room to show them in full.

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Refactor (non-breaking change that only restructures code)
  • Tests (You added tests for code that already exists, or your new feature included in this PR)
  • Documentation Updates
  • Translation Updates
  • Release

Codebase Modernization

  • Updated files to React Hooks
  • Updated files to TypeScript

Before / After

Note: The data in these screenshots is mock data that was created locally.
Single asset vault page - desktop
VaultPageDepositsAllowed

Single asset vault page - mobile
VaultPageMobile

Vault delete - simple view
VaultDeleteSimple

Vault delete - detailed view
VaultDeleteDetailed

Vault deposit
VaultDeposit

Test Plan

All tests pass including new/updated tests for VaultHeader and VaultCreate

…elds

Adds Vault ledger flag decoding (lsfVaultDepositBlocked,
lsfVaultOwnerCanBlockDeposit) and a "Deposits Allowed" indicator on the
Vault page, new tf* flag entries for VaultCreate/VaultSet/VaultDeposit,
and rendering for VaultDelete's new MemoData field, matching the
upstream xrpl4j changes for DGE-7974.

Also fixes long Vault ID/Owner values being truncated or cut off on
the Vault page and across the Vault transaction Simple views, since
there's normally enough room to show them in full.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

@ripple-code-reviewer ripple-code-reviewer Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a clean, well-tested change. The new Vault deposit-blocking flags are decoded and gated correctly (the "Deposits Allowed" row only renders when lsfVaultOwnerCanBlockDeposit is set, and the row's inverse-of-blocked logic matches the tests), the new tf* transaction flag entries live in their own per-transaction-type namespaces with no bit collisions, and the truncation fixes (full Vault ID/Owner display, CSS wrapping via overflow-wrap: anywhere, and the new .vault-id selector) look consistent with the stated goal and are backed by updated tests. I did not find correctness or security issues in the diff. One minor doc nit below.

Covers the LendingProtocolV1_1 additions that were missing alongside the
deposit-blocking work already on this branch:

- VaultKind, SubscriptionDate and RedemptionDate on the Vault page and the
  VaultCreate simple view. Dates are rendered with the same
  convertRippleDate + localizeDate + DATE_OPTIONS treatment Escrow uses, so
  they read as timestamps rather than raw Ripple-epoch seconds.
- CredentialIDs on VaultWithdraw, reusing the shared CredentialIDs row
  component already used by EscrowFinish and PaymentChannelClaim.

VaultKind values live in a new shared vaultUtils so the Vault page and the
transaction view agree on the labels. Fields absent from the xrpl package's
types are read through a cast, matching the existing MemoData pattern.

LEVersion is intentionally not surfaced: it selects legacy vs. cash-basis
accounting for libraries decoding the ledger entry, and is noise for a
human reading the explorer.

@ripple-code-reviewer ripple-code-reviewer Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a well-structured, well-tested MR that adds decoding for the new Vault deposit-blocking flags/fields, new tf* flag entries, VaultDelete MemoData rendering, and fixes truncation of long Vault IDs/Owner addresses. The logic for the new lsfVaultDepositBlocked/lsfVaultOwnerCanBlockDeposit flags is internally consistent (the 'Deposits Allowed' row is correctly gated on canBlockDeposit, and defaults sensibly when flags is undefined). The as-any casts for fields not yet in the xrpl package's types match the documented existing pattern (CredentialIDs). Test coverage for the new behavior (flag combinations, VaultKind branches, MemoData) is thorough. I did not find high-confidence correctness or security issues in the changed lines; only minor consistency/dead-code observations worth a second look.

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.

1 participant