Currently we have addressID matcher which can accept both addressIDs (from address book) and walletIDs (internal wallets). From now on, this will need to be specified in separate fields:

1. addressID for addresses in address book
2. walletID for internal wallets

👍

Any existing policies will be migrated automatically and require no action on your part

Impact

Behaviour

While previously, a single policy having an addressID matcher can take multiple values, each value being either a addressID or walletID, this change will require you to specify two distinct matchers, one containing all addressIDs and another containing walletIDs respectively.

For example, the following policy matcher, where 4a2b6f8b-5077-4d52-8368-07b342c651b3 is addressID and 25ca96e0-9ff5-46d0-9496-2c555593fc99 is an internal walletID, would have been valid before, is now invalid:

[
	{
	  "type": "ADDRESS_ID",
	  "values": [
	  "4a2b6f8b-5077-4d52-8368-07b342c651b3", 
	  "25ca96e0-9ff5-46d0-9496-2c555593fc99"
	  ]
	}
]

Instead, the new policy matcher will have to have one policy for addressIDs:

[
	{
	  "type": "ADDRESS_ID",
	  "values": [
	  "4a2b6f8b-5077-4d52-8368-07b342c651b3"
	  ]
	}
]

and another policy for walletIDs:

[
	{
	  "type": "WALLET_ID",
	  "values": [
	  "25ca96e0-9ff5-46d0-9496-2c555593fc99"
	  ]
	}
]

API driven flows

If you are using APIs to manage your policies, you will need to change the requests in order to fit the new model as described in the behaviour section above.

Particularly, if you are using one policy matcher of ADDRESS_ID to fit addressIDs (from address book) and walletIDs (from internal wallets), then you will need to instead create two policies, one with ADDRESS_ID matcher type whose values contain address book addressIDs only, and another with WALLET_ID type whose values contain internal walletIDs only.

Action items

• Ensure all programmatic policy creation is updated to create two distinct policies for ADDRESS_ID type and WALLET_ID type matchers instead of a single policy
• Verify existing policies to ensure the behaviour is as expected

Timeline

Sandbox deployment: 22nd January 2025

Production deployment: 24th January 2025

References

Create wallet limit API documentation: https://developers.palisade.co/reference/policyservice_createwalletlimit