search

glacislabs / v1-core

Core smart contracts of Glacis v1
Apache License 2.0
7 stars 1 forks source link

CCIP fee fix #5

Closed gusjavaz closed 6 months ago

gusjavaz commented 7 months ago

Additionally this PR:

Replaces XERC20 extension with GXT (GlacisCrossChainToken) Adds counterpart support to GXT

  1. Swaps constructor arguments on LZ Adapter to follow the rest of the adapters approach
  2. Force retriable to true when sendind tokens
  3. Replaces setAdapterChain on CCIP adapter to setGlacisChainIds to follow the rest of the adapters approach
  4. Updates node to 18 on github action
  5. Adds a Dockerfile so tests can work in a common container architecture
gusjavaz commented 6 months ago

w There is a third option which is to have a cross chain token registry like LZ. After reviewing all the options, my opinion is that Glacis should implement an xERC20 address registry, since we should not let Glacis rely completely on the issuer, since the issuer could change the token variant at any time. I guess for now we should only rely on a permissioned Glacis Cross Chain Token Registry where glacis labs can attest the token counterparts. I have modified the PR to reflect this proposal. What do you think?

gusjavaz commented 6 months ago

I've also added a Dockerfile so we can both work in a common container.

jboetticher commented 6 months ago

cross chain token registry like LZ

I didn't know LZ had that, I thought that each OFT had to register their own token variants. But I'm certain that Wormhole had this originally with their token attestation.

the issuer could change the token variant at any time.

If they want to do that, then they should have the ability to do so. Perhaps they are migrating to a new version of their token.

gusjavaz commented 6 months ago

cross chain token registry like LZ

I didn't know LZ had that, I thought that each OFT had to register their own token variants. But I'm certain that Wormhole had this originally with their token attestation.

the issuer could change the token variant at any time.

If they want to do that, then they should have the ability to do so. Perhaps they are migrating to a new version of their token.

The Token attestation service

cross chain token registry like LZ

I didn't know LZ had that, I thought that each OFT had to register their own token variants. But I'm certain that Wormhole had this originally with their token attestation.

the issuer could change the token variant at any time.

If they want to do that, then they should have the ability to do so. Perhaps they are migrating to a new version of their token.

How Glacis could deal with a malicious issuer that changes the token counterpart after setting limits for Glacis?

jboetticher commented 6 months ago

How Glacis could deal with a malicious issuer that changes the token counterpart after setting limits for Glacis?

I'm not sure what the attack is that you're talking about here. Could you expand?

gusjavaz commented 6 months ago

How Glacis could deal with a malicious issuer that changes the token counterpart after setting limits for Glacis?

I'm not sure what the attack is that you're talking about here. Could you expand?

I'll create a separate PR for the token counterpart since it is not related to these fixes. There we can discuss the best approach.

gusjavaz commented 6 months ago

Removed from this PR

  1. Replaces XERC20 extension with GXT (GlacisCrossChainToken)
  2. Adds counterpart support to GXT