Skip to main content

Advanced

This section documents some implementation details of Wrap Lock / Token.

Wrapping tokens​

A typical transfer action is used to move the native tokens to the wraplock contract account on chain A. The beneficiary account on chain B is specified in the memo field. The tokens are locked and the corresponding token reserve balance in the wraplock contract is credited. An inline emitxfer action is also triggered.

The appropriate proof structures are created using the proof server, or another method. These proofs are submitted to one of the issue actions of the wraptoken contract on chain B. They consist of a heavy (issuea) or light (issueb) block proof, plus a proof that the previously mentioned emitxfer action was included in the proven block.

On receiving the proof, the issue action:

  • Performs a search on the processed multi-index table for the presence of the action receipt digest to ensure that this action hasn’t previously been proven.
  • Stores the proof structure in RAM.
  • Makes an inline call to the appropriate checkproof action on the bridge contract to verify the proof.
  • Adds the action receipt digest to the processed multi-index table to prevent double spending.
  • Mints and transfers equivalent wrapped tokens to the beneficiary specified in the emitxfer action generated by the wraplock contract.

Unwrapping tokens​

Any holder of wrapped tokens may redeem them for native assets by calling the retire action of the wraptoken contract on chain B, specifying the quantity and beneficiary account on chain A. The contract removes the wrapped tokens from supply, and triggers an inline emitxfer action.

Again, the appropriate proof structures are created using the proof server, or another method. These proofs are sent to one of the withdraw actions on chain A. They consist of a heavy (withdrawa) or light (withdrawb) block proof, plus a proof that the previous emitxfer action was included in the proven block.

On receiving the proof, the withdraw action:

  • Performs a search on the processed multi-index table for the presence of the action receipt digest to ensure that this action hasn’t previously been proven.
  • Stores the proof structure in RAM.
  • Makes an inline call to the appropriate checkproof action on the bridge contract to verify the proof.
  • Adds the action receipt digest to the processed multi-index table to prevent double spending.
  • Unlocks and transfers equivalent native tokens to the beneficiary specified in the emitxfer action generated by the wraptoken contract.

Exceptional situations​

In the case that the beneficiary named in the transfer or retire actions doesn’t exist on the target chain, or that the beneficiary account is running contract code which rejects the inbound transfer, one of the cancel actions may be used to return the tokens to the owner on the source chain: cancela for using a heavy proof, and cancelb using a light proof.

In order to prevent a possible denial of service attack vector, the cancel actions may only be used at least 15 minutes after the block containing the emitxfer action. This mitigation is necessary because any account may call the issue, withdraw or cancel actions.