Conversation
|
|
||
| The special case `tokenAddress = 0x0` preserves ETH as a first-class supported asset without needing a separate model. | ||
|
|
||
| Each app defines an allowlist of supported tokens. That allowlist is declared in app configuration or deploy metadata and is also enforced by the application logic at runtime. In addition, the contract maintains a global token allowlist so it can reject unsupported assets before custodying them. This allows some apps to stay ETH-only while others support ETH plus selected ERC-20 tokens. |
There was a problem hiding this comment.
For the global allowlist, could you describe how (or if) it can be updated? Especially, is it allowed to remove tokens from the allowList? And what happens in that case to the tokens inside the apps?
There was a problem hiding this comment.
Waiting for the other comment disccussion before thinking about this.
|
|
||
| The special case `tokenAddress = 0x0` preserves ETH as a first-class supported asset without needing a separate model. | ||
|
|
||
| Each app defines an allowlist of supported tokens. That allowlist is declared in app configuration or deploy metadata and is also enforced by the application logic at runtime. In addition, the contract maintains a global token allowlist so it can reject unsupported assets before custodying them. This allows some apps to stay ETH-only while others support ETH plus selected ERC-20 tokens. |
There was a problem hiding this comment.
Why do we need to keep the app allowlist? Isn't the app in charge to decide which tokens can be accepted? In addition, putting the allowlist on chain would make it unmutable, while if it is just inside the wasm, the wasm could implement functions for modifying it.
The only reason I can see to put the contract in charge of checking the allowed tokens for the app is if we want to reduce the possibility to burn tokens, but this possibility is not eliminated, just reduced.
There was a problem hiding this comment.
good observation.
For global allowlist I would remove it completely: I don't see good reasons to add global constraints, we can support any token.
For app allowlist I see 3 different paths:
app allowlist in the contract => we can prevent burn by mistake (or better: unlimited locking), management more complicated
app allowlist managed by the exectuor and saved in the appData (the part of the app state not directly managed by the wasm - where we also save the p521 keys) => executor could do all the checks when a deposit happens before calling the wasm, wasm part simplified but wasm can't change it (only decided at deploy time)
app allowlist saved and managed by the wasm => any request is forwarded, full control on the wasm
Maybe Mikel you could also talk with @domenicohorizen : it's also a product requirement in my opinion
There was a problem hiding this comment.
Are we sure we are going to allow any token? I think it could break a lot of things. Think about rebase tokens, tokens with fees on transfer, etc etc.
There was a problem hiding this comment.
not sure about that: can you highlight the problems? maybe I'm missing something but for us is just important that the token implements the ERC-20 approve + transferFrom => we just need to be able to lock & unlock tokens to the smart contract
3 participants
Only focus in the design doc for now:
Jira task here