How to resolve incorrect lock?
See original GitHub issueI locked an ERC-20 on Eth which was minted on SDK as Coin. Then I locked that Coin on SDK in order to return it to Eth. Of course when doing this you should not lock but instead burn the Coin. I did the incorrect lock instead of burn. After adding error logging to the Eth side it throws an error that says:
> yarn peggy:process 1
yarn run v1.16.0
$ yarn workspace testnet-contracts peggy:process 1
$ truffle exec scripts/sendProcessProphecy.js 1
You can improve web3's peformance when running Node.js versions older than 10.5.0 by installing the (deprecated) scrypt package in your project
You can improve web3's peformance when running Node.js versions older than 10.5.0 by installing the (deprecated) scrypt package in your project
Using network 'ganache'.
Fetching Oracle contract...
Attempting to send processBridgeProphecy() tx...
Returned error: VM Exception while processing transaction: revert Token must be a whitelisted bridge token -- Reason given: Token must be a whitelisted bridge token.
Done in 9.56s.
What are the methods available for undoing an incorrectly made relay? In a similar vein: what are the methods for relaying a transactions which was originally missed?
Issue Analytics
- State:
- Created 4 years ago
- Comments:12 (4 by maintainers)
Top Results From Across the Web
Door Lock Problems and How to Fix Them | HomeServe USA
Here are several simple ways you may be able to fix common door lock problems without calling in a professional.
Read more >Key Stuck In Lock? Try This Easy Solution! - YouTube
Today, Uriah of Guardian Safe & Lock wanted to go over the easy solution to this problem. When you pull your key from...
Read more >How to fix lock screen pin lock issues for Android? - YouTube
Having issues on with your lockscreen on your Android lollipop device? This video has got you covered, if this didn't fix your problem...
Read more >Resolve blocking problem caused by lock escalation - SQL ...
This article describes how to determine whether lock escalation is causing blocking and how to resolve the problem.
Read more >Diagnosing and resolving locking problems - IBM
To resolve a locking problem, you need to start by diagnosing the type of lock event causing the SQL query performance slowdown, or...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
It’s true having the fully featured metadata would be a more complete solution. I don’t think there’s that much wrong with just settling on a naming convention and enforcing it at the bridge level though. For example if underscore was the decided demarcation, the bridge could restrict usage to only denoms that did not contain any underscores. Probably it would be good to do something a little less common, maybe
::
but the idea stays the same.Checking the whitelist from the CLI is another option but I agree it would be good not to bog down the CLI with that kind of action. Maybe adding the relayer as an endpoint that the CLI could query for that information is an option.
Your outlined solution makes sense beyond the fact that the relayer isn’t capable of trying a failed transaction again. There’s also the general problem of whitelisting a new token which can only be done by the operator. It seems like maybe any token coming from an SDK chain should be automatically whitelisted upon generation?
For the sake of concrete actions that can be made on the current codebase that would prevent an invalid lock, I’d suggest using a single namespace to denote a token coming from on chain or off chain. The complexities of tracking chain id and bridge address are to allow multiple chains and multiple instance of a bridge on the same chain from interacting with a single sdk chain. I think that is out of scope for this version of peggy and realistically we’re talking about only one sdk chain talking to one eth chain via one bridge contract. adding a prefix like
peg::
to denoms on the sdk side or on the eth side would be enough to distinguish the origin of the asset and automate the decision to burn or lock.Alternatively an improvement to the UX of the relayer that is able to check the status of relayed events and detect when one failed and try again would be a method of supporting the userflow you outlined as well.
I like the prefix solution better as it is able to prevent a mishap at the level of the state machine. Plus there might be other situations where it’s good to be able to tell what category of asset a denom is within the SDK. Being able to check if it was an wrapped asset or not could be useful. There’s also been some talk about using something like a metadata module to store information about a coin, like vesting. https://github.com/cosmos/cosmos-sdk/issues/1980 https://github.com/cosmos/cosmos-sdk/issues/4911