Currently, our data models in "ENSAnalytics" / our referral program logic uses only a NormalizedAddress to identify a referrer.
It will be more mature for us to update every instance of this approach so that instead we use AccountId from the enssdk package.
I imagine there may be cases in our existing logic where you're currently using a NormalizedAddress as some form of a key in a data structure to uniquely identify each referrer. Based on how TypeScript works, it won't be appropriate to use an AccountId like this because it will determine equality by object reference rather than object value. To fix this, if you need to generate a key, you can do it via the stringifyAccountId helper function which will convert an AccountId to a string which is then safe to use as a key which will be compared by value.
You can also make use of parseAccountId in the ensnode-sdk package to attempt to convert back from a string to a valid AccountId.
The accountIdEqual helper function in the ensnode-sdk package may also be useful for you.
These updates should also be applied to our API routes. For example, the API route for requesting details about a specific referrer should be enhanced so that instead of taking as input only an address it takes as input a query param identifying the full AccountId of the referrer through a string that is formatted as a CAIP-10 account Id as can be produced through our stringifyAccountId helper function.
These updates should also be applied to the client helper functions in packages/ens-referrals/src/client.ts so that wherever the client helper functions are currently taking just an address as a param they should instead take an AccountId. The logic to convert from the provided AccountId into it's serialized representation via stringifyAccountId should happen internally within the client's logic.
Currently, our data models in "ENSAnalytics" / our referral program logic uses only a
NormalizedAddressto identify a referrer.It will be more mature for us to update every instance of this approach so that instead we use
AccountIdfrom theenssdkpackage.I imagine there may be cases in our existing logic where you're currently using a
NormalizedAddressas some form of a key in a data structure to uniquely identify each referrer. Based on how TypeScript works, it won't be appropriate to use anAccountIdlike this because it will determine equality by object reference rather than object value. To fix this, if you need to generate a key, you can do it via thestringifyAccountIdhelper function which will convert anAccountIdto astringwhich is then safe to use as a key which will be compared by value.You can also make use of
parseAccountIdin theensnode-sdkpackage to attempt to convert back from astringto a validAccountId.The
accountIdEqualhelper function in theensnode-sdkpackage may also be useful for you.These updates should also be applied to our API routes. For example, the API route for requesting details about a specific referrer should be enhanced so that instead of taking as input only an address it takes as input a query param identifying the full
AccountIdof the referrer through a string that is formatted as a CAIP-10 account Id as can be produced through ourstringifyAccountIdhelper function.These updates should also be applied to the client helper functions in
packages/ens-referrals/src/client.tsso that wherever the client helper functions are currently taking just an address as a param they should instead take anAccountId. The logic to convert from the providedAccountIdinto it's serialized representation viastringifyAccountIdshould happen internally within the client's logic.