You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently sending payment in crypto is quite risky. There can be a typo in address or the wrong address is selected, then the fund is lost forever as transactions are irreversible.
There are attempts to address this issue, such as Cash Account, which addresses are shared publicly as registries. Or the barcode scanner also useful to avoid the mistake. However there are still usability issues and risks associated.
Hereby, a new proposal aim to address the risk of lost fund.
When the sender sends the fund to the recipient, there would be an option for the sender to set a claim code, together with an expiry time period (say 15m, 1h, 2h, 4h, 8h, 24h, etc...)
The claim code is autogenerated for now. Consists of 4 or 6 digits.
Once the fund is sent, the claim code must be passed to the recipient in order to claim the fund
If after the expiry period, the fund is not claim, it will be returned back to the recipient
The sender must ensure the fund is not spent before it is claimed. Otherwise the fund will be unredeemable to the users
This should be proposed at protocol level, so that the fund is locked to avoid double spending. Alternatively this could be also done at BWS layer, given that the sender has the responsibility to keep the fund intact before the recipient can claim it. This will need to be further discussed with ABC team.
The text was updated successfully, but these errors were encountered:
kensauruss
changed the title
Claim code for AbcPay using BWS
Claim code for AbcPay using AWS
Apr 17, 2022
Currently sending payment in crypto is quite risky. There can be a typo in address or the wrong address is selected, then the fund is lost forever as transactions are irreversible.
There are attempts to address this issue, such as Cash Account, which addresses are shared publicly as registries. Or the barcode scanner also useful to avoid the mistake. However there are still usability issues and risks associated.
Hereby, a new proposal aim to address the risk of lost fund.
When the sender sends the fund to the recipient, there would be an option for the sender to set a claim code, together with an expiry time period (say 15m, 1h, 2h, 4h, 8h, 24h, etc...)
The claim code is autogenerated for now. Consists of 4 or 6 digits.
Once the fund is sent, the claim code must be passed to the recipient in order to claim the fund
If after the expiry period, the fund is not claim, it will be returned back to the recipient
The sender must ensure the fund is not spent before it is claimed. Otherwise the fund will be unredeemable to the users
This should be proposed at protocol level, so that the fund is locked to avoid double spending. Alternatively this could be also done at BWS layer, given that the sender has the responsibility to keep the fund intact before the recipient can claim it. This will need to be further discussed with ABC team.
The text was updated successfully, but these errors were encountered: