Skip to content

Conversation

@mkflow27
Copy link
Contributor

@mkflow27 mkflow27 commented Sep 26, 2025

Closes #830

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

@changeset-bot
Copy link

changeset-bot bot commented Sep 26, 2025

🦋 Changeset detected

Latest commit: 1e9d945

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
backend Minor

Not sure what this means? Click here to learn what changesets are.

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

this.mutateBalances = Boolean(mutateBalances);

//call to super ensures this array access is safe
if (tokens[0].isUnderlyingEqual(swapAmount.token)) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have almost fully replaced the Token with BaseToken (which does not include wrapped). This led to quite a big dif.

@mkflow27 mkflow27 marked this pull request as ready for review October 14, 2025 20:35
@franzns
Copy link
Collaborator

franzns commented Dec 15, 2025

@brunoguerios @mkflow27 can this be merged?

@mkflow27
Copy link
Contributor Author

@brunoguerios @mkflow27 can this be merged?

Hey @franzns This required balancer/b-sdk#725 to be merged. We'll take a look

@brunoguerios
Copy link
Member

I released b-sdk with the required updates, but since it's a major version bump I need to make sure things are working as expected over here. It should likely be ready for review tomorrow

@brunoguerios brunoguerios requested a review from franzns December 17, 2025 13:21
@brunoguerios brunoguerios merged commit eeafe7c into v3-canary Dec 17, 2025
1 check passed
@brunoguerios brunoguerios deleted the mkflow27/issue830 branch December 17, 2025 13:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SOR - Evaluate if Token still needs to differentiate address/wrapped

4 participants