How to resolve incorrect lock?

I 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?

[okwme]

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.

[okwme]

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