Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem: not possible to cancel SendToEthereum transactions (fixes #389) #532
Problem: not possible to cancel SendToEthereum transactions (fixes #389) #532
Changes from 17 commits
d9f7ee7
9ae251a
345bcd1
fa5865f
a0cc89d
13021a3
cb5b033
a481f3e
557cdf5
5c514c1
5919cc3
13492b2
e46f813
fd763a5
1e7fccc
4f37110
17ea59f
7dc28b4
525befb
8559d28
907e625
5b83554
01eae9e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without having to migrate all existing contract, it is possible to create a wrapper over the CRC20 to be able to call
__CronosSendToEthereum
and have a separate supply from the original CRC20It would be cleaner to remove
send_to_ethereum
from the CRC20.sol and remove the _v2 here however this might change the bytecode of the original CRC20 standard (even though nobody is using this method now)Any opinion @tomtau @yihuang
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with the standard extension, and deprecate the
send_to_ethereum
from the original one.But existing contracts still need to migrate code to support the gravity bridge, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
another idea is to have a wrapper over exsting CRC20 contract to be able to add the ability to bridge.
For example having
ETH_VVS
will be a wrapper ofVVS.sol
and exposesend_to_ethereum
andwrapping/unwrapping
functionsThe 1-1 supply control will be guarantee by the smart contract
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest documenting these architectural decisions: https://github.com/crypto-org-chain/cronos/blob/main/docs/architecture/adr-template.md + getting some feedback from dApp developers on it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's still a contract migration, the client need to use a different contract address, but internally it reuse the old contract to avoid state migration, right?
I think dapps could have multiple solutions to do this, sometimes even have the upgradability build-in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the client need to use a different contract address, but internally it reuse the old contract to avoid state migration
Why does it need to use old contract? Mapping between gravitydenom <-> contract address will be done on the wrapped contract.
The drawback is that to be able to send to ethereum, one needs to wrap its token first (or unwrap for the opposite direction) but that can be integrated seeminglessly by the Dapp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, you mean a 1-to-1 token wrapping contract, I guess for erc20, user will need to do a) approve, b) swap, c) send_to_ethereum, right?