Summary
Reject MsgCreateVaultRequest when payment_denom is set and differs from underlying_asset. The vault should only be creatable with a single denom: payment_denom must be empty (defaults to underlying_asset) or equal to it.
Motivation
The plan is to flatten the underlying/payment split into a single underlying denom in a future release. The production nvYLDS vault already runs with underlying == payment, so nothing in production uses mixed denoms. Blocking mixed-denom creation now prevents new integrations (nvHOME, Blacklake) from building against a configuration we intend to remove.
Scope
- Add validation (msg
ValidateBasic and/or keeper CreateVault) rejecting payment_denom != underlying_asset.
initial_payment_nav becomes effectively dead at creation time since it is only required when the denoms differ; validation should reject it accordingly.- Existing vaults with mixed denoms (if any on non-production networks) are untouched; this only gates creation.
Out of scope
- Removing the payment denom concept and related endpoints entirely (separate deprecation effort).
Summary
Reject
MsgCreateVaultRequestwhenpayment_denomis set and differs fromunderlying_asset. The vault should only be creatable with a single denom:payment_denommust be empty (defaults tounderlying_asset) or equal to it.Motivation
The plan is to flatten the underlying/payment split into a single underlying denom in a future release. The production nvYLDS vault already runs with underlying == payment, so nothing in production uses mixed denoms. Blocking mixed-denom creation now prevents new integrations (nvHOME, Blacklake) from building against a configuration we intend to remove.
Scope
ValidateBasicand/or keeperCreateVault) rejectingpayment_denom != underlying_asset.initial_payment_navbecomes effectively dead at creation time since it is only required when the denoms differ; validation should reject it accordingly.Out of scope