Description:
The current data model uses DataKey::Vault(Address) — a 1:1 mapping between tenant address and a single vault. A tenant cannot:
Save for two different rental properties simultaneously
Start a new vault after completing a lease cycle without destroying the old one
Separate savings for rent vs. a security deposit goal
Proposed change: Update the vault key to DataKey::Vault(Address, u32) where the second component is a vault ID counter per tenant (similar to how EscrowIdCounter works for escrows). Add a create_vault_v2 (or deprecate and update create_vault) that returns the new vault ID, and update all query/mutation functions to accept a vault_id parameter.
Migration path: Existing single-vault tenants keep vault ID 1.
Acceptance criteria:
A single tenant address can hold N vaults
create_vault returns a vault_id: u64
deposit, withdraw, execute_rent_payment accept vault_id
get_vault updated to accept vault_id
Tests verify multi-vault scenario
Description:
The current data model uses DataKey::Vault(Address) — a 1:1 mapping between tenant address and a single vault. A tenant cannot:
Save for two different rental properties simultaneously
Start a new vault after completing a lease cycle without destroying the old one
Separate savings for rent vs. a security deposit goal
Proposed change: Update the vault key to DataKey::Vault(Address, u32) where the second component is a vault ID counter per tenant (similar to how EscrowIdCounter works for escrows). Add a create_vault_v2 (or deprecate and update create_vault) that returns the new vault ID, and update all query/mutation functions to accept a vault_id parameter.
Migration path: Existing single-vault tenants keep vault ID 1.
Acceptance criteria:
A single tenant address can hold N vaults
create_vault returns a vault_id: u64
deposit, withdraw, execute_rent_payment accept vault_id
get_vault updated to accept vault_id
Tests verify multi-vault scenario