This shows her there are enough tokens at the destination and that her proposed bridging is allowed.
The response also shows her the fees she would expect to pay (fee_token_total_dec) as part of this transaction.
Step 2 : Building bridge tx
Alice would now build the payload data for the transaction based on the instructions found on the building bridge deposit page.
The expected structure of the payload is shown below, it contains information about where the funds she is bridging will be sent and an agreement of the amount she will receive and the fee that will be charged.
This should then be encrypted and might yield something like this:
It is extremely important to correctly calculate the dest_amount as this will be the amount transferred at the destination. If this does not account for the fee (i.e. deposit amount - fee obtained from the API call) the transaction will be rejected.
Step 3 : Setting spending allowance
Alice should make sure she has granted sufficient allowance to the bridge contract.
To do this she would then call getBridgeContract on the chain she wants to bridge from, in this case Goerli. The call would might looks like this.
/api/getBridgeContract?chain=5
Returning
Using this address she can approve the bridge contract to spend 0.1 UNI.
Step 4 : Sending bridge tx
Bringing everything together, using this address and the payload information, Alice can then build and send her transaction to the bridge contract.
Once the transaction has been broadcast, she will see confirmation on chain.
Step 5 : Watch status of tx on neuron
Alice should then wait while the transaction is being confirmed by the chain watchers and credited at her destination chain.
She can do this by calling getHistory with the source transaction hash as the id paramater to see the current status of her bridge transaction.
Step 6 : Funds credited at distination
Once the bridging is complete, the field destination_chain_tx will contain the transaction hash of the funds being credited at the destination chain.