Compromised Address

The above figure displays an example of a user at address 0x…1 (Bob) attempting to send assets to user 0x…2 (Alice). But there’s an issue: Alice’s keys have been compromised and a bad actor has access to all of Alice’s funds.

Upon creation of the Capsule Shipment, Bob specifies to send his Capsuled assets to 0x…2 (Alice) – but Bob has also attached a password, “Hunter2”. On-chain, this password is stored within the Capsule Fulfillment Center as a hashed value of the password and a salt. Without the password, Alice is unable to properly accept this shipment and receive her Capsuled assets.

Thankfully, even though Alice’s keys have been compromised, the hacker is still unable to access Alice’s shipment: he does not know the password attached to the shipment coming to Alice. As such, Alice simply lets Bob know that her account has been compromised, and for Bob to change the shipment to a new address, 0x…3, which Alice has properly secured. Bob does so, and Alice is able to properly accept the assets shipped at address 0x…3. Bob may even change the shipment acceptance password, should he like. The hacker is unable to receive Alice’s shipped assets at 0x…2 or at 0x…3. No assets were lost due to a compromised address, even though the address was correct.

If this transaction were to have been broadcasted and accepted as is (without using CPaS, directly from 0x…1 to 0x…2), there is an overwhelming chance that all assets are lost to Alice’s hacker – who can steal all of the assets sent to her address at 0x…2. This again results in a loss for Bob (who owned the funds) and Alice (who has her funds stolen). Additionally, had multiple assets been bundled within a Capsule - this would have saved multiple assets from being lost. This situation can also be easily averted by using CPaS.