Fix TBRv3 library issues #104
Conversation
…d them to peerDependency
| const allowedTokenAddresses = this.config?.allowedTokenAddresses || []; | ||
| const isWhitelistConfigAvailable = this.config && allowedTokenAddresses.length > 0; |
There was a problem hiding this comment.
What's all this about? This does not exactly fit the theme of the repo name of "arbitrary-token-transfers", no?
There was a problem hiding this comment.
@nonergodic It is funny because I asked the same question. They want this restriction to prevent users from bridging useless tokens. By default is inactive and I believe that this feature will only be used in Portal Bridge UI.
@solanoepalacio can give you more default about this.
There was a problem hiding this comment.
It sounds to me that a deny list would be more desirable in that case 🤔. But I'm not sure. I'll ask.
There was a problem hiding this comment.
A few notes that shed a -little- bit of light to this.
There's two limitations that prevent to fully embracing the "arbitrary token transfers" nature of this protocol:
- At the UI level the user doesn't have the ability to just select "any" token. Connect is configured with a set of supported tokens at bootstrap. I think @adam and @Art (from foundation and whlabs respectively) are working on adding the ability to enter a token address. Probably they are doing it directly against the token bridge, but we'd need to check.
- To fully support "arbitrary-token-transfers" with automatic relaying we are faced with the problem of needing attestations in the target chain. IOW: While the relayer can't attest a token that hasn't been transferred before to a chain, we can't offer automatic ATT to users because probably the relay will fail. (There a ton of considerations on the UX side that make this implementation trickier than one may think).
For this reason, there's a "phased" plan to get to Automatic Token Transfers. Plan is like so IIRC:
- Release TBRv3 with a whitelist of the 30 most used tokens in each chains (this PR)
- Make portal support any token that has already been attested
- Add automatic attestation on the relayer and make the final release of Automatic Token Transfers (with automatic relaying)
| const allowedTokenAddresses = this.config?.allowedTokenAddresses || []; | ||
| const isWhitelistConfigAvailable = this.config && allowedTokenAddresses.length > 0; |
There was a problem hiding this comment.
It sounds to me that a deny list would be more desirable in that case 🤔. But I'm not sure. I'll ask.
peerDependencyto avoid the collision of multiple Wormhole SDK versions in one project.