refactor: replace wrapped with address

[mkflow27]

Closes #830

Working off of this feature branch. balancer/b-sdk#725

Investigating jareks suggestion of uncoupling the sdk / sor Token types.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4e1c4ba

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[mkflow27]

@brunoguerios I am slowly progressing through replacing references to Token with BaseToken (working name). Commenting here as I had to refactor to use functionality of the BaseToken here now instead of Token.

There are other opportunities for me to replace Token with BaseToken (think TokenAmount). However, if I do these changes in the sdk. (TokenAmount can either accept Token or BaseToken in the constructor I am getting alot of downstream build errors in the sdk.

So, the question here is:

• Would a "perfect" refactor also need to change how TokenAmount is used?

[brunoguerios]

Can you please elaborate on which changes would be required to TokenAmount?
Things such as replacing isUnderlyingEqual with isSameAddress make sense 👍

Ps: regarding variable naming, my suggestion would be to keep Token as the base token (without wrapped) and have a NativeToken (with wrapped). Which should result in less downstream changes compared to renaming Token with BaseToken.

Ps2: I'd expect TokenAmount could accept only Token (without wrapped) - if that's not the case, then it's important to evaluate if this refactor won't increase complexity in any way. The overall idea is to aim for more simplicity and type safety.