adds VaultDepositBlock flag

[Tapanito]

This PR updates the VaultDeposit transaction logic with the following features:

1. We introduce a functionality for the Vault Owner to block/unblock vault deposits.
2. We introduce a new tfVaultDonate flag, which allows the Vault Owner to donate assets into a Vault.

Motivation

Blocking

There are situations where a Vault Owner may need to block incoming deposits to protect users—for example, if a vault becomes insolvent.

Donation

Once the Vault becomes insolvent, the donation feature provides a method for the Vault Owner to make the depositors whole.

Implementation

• Introduces the lsfVaultDepositBlocked flag on the Vault ledger entry, indicating that new deposits are prohibited.
• This flag can be toggled via the VaultSet transaction using the tfVaultDepositBlock and tfVaultDepositUnblock flags.
• Introduces tfVaultDonate flag to the VaultDeposit transaction.

High Level Overview of Change

Context of Change

Type of Change

• New XLS Draft
• XLS Update (changes to an existing XLS)
• XLS Status Change (e.g., Draft → Final, Draft → Stagnant)
• Process/Meta (changes to CONTRIBUTING.md, XLS-1, templates, etc.)
• Infrastructure (CI, workflows, scripts, website)
• Documentation (README updates, typo fixes)

[dangell7]

I'm surprised this isn't a regulatory issue.

[Tapanito]

@dangell7 could you elaborate further please?

[dangell7]

@dangell7 could you elaborate further please?

The core issue is that this flag can be toggled unilaterally by the vault operator at any time, with no governance process, no advance disclosure, and no investor consent mechanism at the protocol layer.

In traditional finance, selectively blocking new deposits while existing investors can still exit (a "soft close") is legal, but it must be disclosed upfront and cannot be deployed opportunistically.

A safer design would be to make this flag immutable after vault creation, set once, known to all investors before they ever deposit.

[Tapanito]

The core issue is that this flag can be toggled unilaterally by the vault operator at any time, with no governance process, no advance disclosure, and no investor consent mechanism at the protocol layer.

In traditional finance, selectively blocking new deposits while existing investors can still exit (a "soft close") is legal, but it must be disclosed upfront and cannot be deployed opportunistically.

A safer design would be to make this flag immutable after vault creation, set once, known to all investors before they ever deposit.

Do you mean similar to lsfMPTCanLock flag, which indicates that an MPT may be locked by the issuer at any time?

[mvadari]

There seems to be some overlap between this PR and #463 (in that this PR seems like it's also doing some general updates). Can we keep them separate?

[Tapanito]

There seems to be some overlap between this PR and #463 (in that this PR seems like it's also doing some general updates). Can we keep them separate?

Feel free to ignore this PR for now.

[mvadari]

There seems to be some overlap between this PR and #463 (in that this PR seems like it's also doing some general updates). Can we keep them separate?

Feel free to ignore this PR for now.

Can we switch it to a draft PR then?

[ximinez]

Forgot to post this yesterday along with XRPLF/rippled#6361

[ximinez]

It's incorrect to check the default ripple flag during a transfer. You need to check the "no ripple" flag on the relevant trustlines.