Start an In-flight Exit
Exits allow a user to withdraw funds from the OMG Network back onto the root chain. There are two types of exit: standard exits and in-flight exits (IFEs). This section will cover in-flight-exits.
A transaction is considered to be in-flight if it has been broadcasted but not yet been included in the Childchain. It may also be in-flight from the perspective of an individual user if that user does not have access to the block where said transaction is included.
A user may consider an exit in-flight in the following scenarios:
The user has signed and broadcast a transaction but is unable to verify its inclusion in a block.
The user can see that the transaction has been included in a block, but believes that the block is invalid due to a dishonest operator.
A user can initiate an IFE regardless of whether the above is correct, but one must commit an exit bond
. The purpose of the exit bond
is to deter users from initiating exits dishonestly, as this bond will be awarded to any party who successfully proves that the exit is dishonest.
Implementation
To access network features from your application, use our official libraries:
Requires Node >= 8.11.3 < 13.0.0
2. Import dependencies
In-Flight exit involves using 3 omg-js
objects. Here's an example of how to instantiate them:
web3_provider_url
- the URL to a full Ethereum RPC node (local or from infrastructure provider, e.g. Infura).
plasmaContractAddress
-CONTRACT_ADDRESS_PLASMA_FRAMEWORK
for defined environment.
watcherUrl
- the Watcher Info URL for defined environment (personal or from OMG Network).
3. Start an in-flight exit
To start an in-flight exit, you need to create a new transaction that has been signed but hasn't been submitted to the network.
A transaction is considered to be “in-flight” if it has been broadcasted but not yet been included in the Childchain. It may also be in-flight from the perspective of an individual user if that user does not have access to the block where the defined transaction is included.
The in-flight exit process is the same for both ETH and ERC20 UTXOs. The tutorial shows how to work with ERC20 tokens. For working with ETH, change
erc20Exit
intoethExit
across the code sample.
gasLimit
- gas limit for your transaction. Please check the current data on Gas Station or similar resources.
An in-flight exit creates an exit receipt. Each exit has an ID that identifies it. After an in-flight exit starts, you'll have to wait for a challenge period before you can process that exit and receive your funds back on Ethereum Network.
Lifecycle
A user calls the
hasToken
function on thePlasmaFramework
contract to check if there's an exit queue for the token in question. If no exit queue is registered, a user needs to register it using theaddToken
function. The correspondingPlasmaFramework
contract functions used in this step arehasExitQueue
andaddExitQueue
. This step is optional but it was included because it prevents any potential issues a user may encounter during an exit.A user calls the
inFlightExitGetData
function on the Watcher to get the necessary exit data to start a standard exit. A transaction is termed exitable if it is correctly formed and properly signed by the owner(s) of the transaction input(s).A user calls the
startInFlightExit
function on thePaymentExitGame
contract and commits an exit bond to the exit.A user calls the
piggybackInFlightExitOnInput
orpiggybackInFlightExitOnOutput
function on thePaymentExitGame
contract to piggyback on in-flight exit input or output call. Such a process is required for every in-flight exit before proceeding to the processing stage.After a challenge period a user can process this exit.
You can only exit one UTXO at a time. It is therefore recommended to merge your UTXOs if you would like to exit multiple ones.
Piggybacking
Once an in-flight exit is initiated, the Watcher emits a piggyback_available
event.
This means that a user can piggyback
onto the in-flight exit. This requires placing a piggyback bond
on a UTXO from the available set in order to claim ownership and receive it on the root chain once the exit is finalized.
To successfully withdraw an output out
to a transaction tx
, a transaction tx
must prove that transaction is both exitable and canonical.
There are specific scenarios when a user wants to exit the inputs in a non-canonical transaction. It must be established that the transaction is indeed non-canonical for this to be successful. Because a transaction is either canonical or non-canonical, you can withdraw either its inputs or outputs, not both.
The owner of an input can piggyback
with the following call:
Demo Project
This section provides a demo project that contains a detailed implementation of the tutorial. If you want to integrate with the OMG Network, you can use this sample to significantly reduce the time of development. You also get step-by-step instructions and sufficient code guidance.
JavaScript
For running a full omg-js
code sample for the tutorial, please use the following steps:
Clone omg-js-samples repository:
Create
.env
file and provide the required configuration values.Run these commands:
Open your browser at http://localhost:3000.
Select
Start an In-flight ETH Exit
on the left side, observe the logs on the right.
Code samples for all tutorials use the same repository —
omg-js-samples
, thus you have to set up the project and install dependencies only one time.
Last updated