-
Notifications
You must be signed in to change notification settings - Fork 18
Reference information for FA bridging calls and events #367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
494f641
a145af9
ed3c98d
599dc46
a667caa
3d8a58c
fce8a8a
72f4eb3
15da368
d27fa0e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -32,7 +32,7 @@ The process of bridging FA-compatible tokens from layer 1 to Etherlink (also kno | |
| For information about token access control, see [Token standards](https://docs.tezos.com/architecture/tokens#token-standards) on docs.tezos.com. | ||
|
|
||
| 1. The user calls the helper contract's `deposit` entrypoint. | ||
| The request includes the amount of tokens to bridge, the address of the Etherlink Smart Rollup, and the user's Etherlink wallet address, but not the tokens themselves. | ||
| The request includes the address of the Etherlink Smart Rollup, the user's Etherlink account address, and the amount of tokens to bridge, but not the tokens themselves. | ||
|
|
||
| 1. The token bridge helper contract stores the address of the Etherlink Smart Rollup and the user's Etherlink address temporarily. | ||
|
|
||
|
|
@@ -55,6 +55,12 @@ The request includes the amount of tokens to bridge, the address of the Etherlin | |
| 1. Any user can call the FA bridging precompiled contract's `claim` function, which causes the contract to call the ERC-20 proxy contract. | ||
| For tokens supported by the bridge, an automated program calls the `claim` function for you. | ||
|
|
||
| You can call the `claim` function yourself with this ABI, using the `depositId` field from the event: | ||
|
|
||
| ``` | ||
| claim(uint256 depositId) | ||
| ``` | ||
|
|
||
| 1. The ERC-20 proxy contract mints the equivalent tokens and sends them to the user's Etherlink account. | ||
|
|
||
| This diagram is an overview of the process of bridging tokens from layer 1 to Etherlink: | ||
|
|
@@ -93,3 +99,209 @@ This transaction includes the target layer 1 address. | |
| This diagram is an overview of the process of bridging tokens from Etherlink to layer 1: | ||
|
|
||
| <img src="/img/bridging-withdrawal-fa.png" alt="Overview of the FA token bridging withdrawal process" style={{width: 500}} /> | ||
|
|
||
| ## Event reference | ||
|
|
||
| The contracts that manage the FA bridge emit several events. | ||
|
|
||
| ### Decoding event information | ||
|
|
||
| You can get information about events from the logs of the FA bridging precompiled contract via the Etherlink indexer at this link: https://explorer.etherlink.com/address/0xff00000000000000000000000000000000000002?tab=logs. | ||
|
|
||
| You can also decode the information in events with toolkits such as Ethers.js. | ||
| For example, this JavaScript program decodes the information from a `QueuedDeposit` event and prints the payload fields: | ||
|
|
||
| ```javascript | ||
| const { ethers } = require("ethers"); | ||
|
|
||
| // Data from the event | ||
| // Topic | ||
| const topic = "0xb02d79c5657e344e23d91529b954c3087c60a974d598939583904a4f0b959614"; | ||
| // Indexed field 1 | ||
| const index1 = "0x9d4704c610c2ca997e1ad4d4062e09bee26bb5136598b0e525ed357da99bd602"; | ||
| // Indexed field 2 | ||
| const index2 = "0x00000000000000000000000001f07f4d78d47a64f4c3b2b65f513f15be6e1854"; | ||
| // Event data payload | ||
| const eventData = "0x0000000000000000000000000000000000000000000000000000000000004ddb000000000000000000000000953d1668bc03e0ee9145a7c4f79956b73db90b67000000000000000000000000000000000000000000000000000000012a05f2000000000000000000000000000000000000000000000000000000000000af1a770000000000000000000000000000000000000000000000000000000000000010"; | ||
|
|
||
| const abi = [ | ||
| "event QueuedDeposit(uint256 indexed ticketHash, address indexed proxy, uint256 nonce, address receiver, uint256 amount, uint256 inboxLevel, uint256 inboxMsgId)" | ||
| ]; | ||
|
|
||
| const iface = new ethers.Interface(abi); | ||
|
|
||
| const log = { | ||
| topics: [ | ||
| topic, | ||
| index1, | ||
| index2, | ||
| ], | ||
| data: eventData, | ||
| }; | ||
|
|
||
| // Parse the event log | ||
| const parsed = iface.parseLog(log); | ||
|
|
||
| // Print the non-indexed fields | ||
| console.log(JSON.stringify(parsed.args, (_, v) => typeof v === 'bigint' ? v.toString() : v)); | ||
| ``` | ||
|
|
||
| The result is a list of the decoded fields, in this case, the nonce, receiving address, amount, block level, and message ID for the deposit: | ||
|
|
||
| ```json | ||
| [ | ||
| "71138596315992044722794716610043613304890979059019361625149303880140533257730", | ||
| "0x01F07f4d78d47A64F4C3B2b65f513f15Be6E1854", | ||
| "19931", | ||
| "0x953D1668BC03e0EE9145A7c4F79956b73db90B67", | ||
| "5000000000", | ||
| "11475575", | ||
| "16" | ||
| ] | ||
| ``` | ||
|
|
||
| ### `QueuedDeposit` event | ||
|
|
||
| When a deposit is ready to be claimed, the FA bridging precompiled contract (`0xff0...0002`) emits a `QueuedDeposit` event. | ||
|
|
||
| The ABI for this event is: | ||
|
|
||
| ```solidity | ||
| event QueuedDeposit( | ||
| uint256 indexed ticketHash, | ||
| address indexed proxy, | ||
| uint256 nonce, | ||
| address receiver, | ||
| uint256 amount, | ||
| uint256 inboxLevel, | ||
| uint256 inboxMsgId | ||
| ); | ||
| ``` | ||
|
|
||
| The topics for this event are: | ||
|
|
||
| Field | Type | Description | ||
| --- | --- | --- | ||
| Signature | `keccak256` | `QueuedDeposit(uint256, address)` | ||
| `ticketHash` | uint256 | The hash of the ticket that represents the transferred tokens, computed as `keccak256(L1 ticketer + content)` | ||
| `proxy` | address | The proxy address through which the deposit is routed | ||
|
|
||
| The payload includes these fields: | ||
|
|
||
| Field | Type | Description | ||
| --- | --- | --- | ||
| `nonce` | uint256 | The global counter for the transaction | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Accross the doc we use Also here "The global counter for the transaction" is false, its the deposit id. |
||
| `receiver` | address | The Etherlink address that receives the tokens | ||
| `amount` | uint256 | The amount of tokens in the transaction | ||
| `inboxLevel` | uint256 | The layer 1 block in which the deposit was submitted | ||
| `inboxMsgId` | uint256 | An identifier for the Smart Rollup inbox message | ||
|
|
||
| ### `Deposit` event | ||
|
|
||
| When a deposit has been claimed, the FA bridging precompiled contract (`0xff0...0002`) emits a `Deposit` event. | ||
|
|
||
| The ABI for this event is: | ||
|
|
||
| ```solidity | ||
| event Deposit( | ||
| uint256 indexed ticketHash, | ||
| address ticketOwner, | ||
| address receiver, | ||
| uint256 amount, | ||
| uint256 inboxLevel, | ||
| uint256 inboxMsgId | ||
| ); | ||
| ``` | ||
|
|
||
| The topics for this event are: | ||
|
|
||
| Field | Type | Description | ||
| --- | --- | --- | ||
| Signature | `keccak256` | `Deposit(uint256)` | ||
| `ticketHash` | uint256 | The hash of the ticket that represents the transferred tokens, computed as `keccak256(L1 ticketer + content)` | ||
|
|
||
| The payload includes these fields: | ||
|
|
||
| Field | Type | Description | ||
| --- | --- | --- | ||
| `ticketOwner` | address | The ERC-20 proxy contract that manages the tokens or, in some cases, the account receiving the deposited tokens | ||
| `receiver` | address | The Etherlink account receiving the deposited tokens | ||
| `amount` | uint256 | The amount of tokens | ||
| `inboxLevel` | uint256 | The layer 1 block in which the deposit was submitted | ||
| `inboxMsgId` | uint256 | An identifier for the Smart Rollup inbox message, which you can use to find the corresponding `QueuedDeposit` event and the Etherlink address that receives the tokens | ||
|
|
||
| ### `Withdrawal` event | ||
|
|
||
| When an account initiates a withdrawal, the FA bridging precompiled contract (`0xff0...0002`) emits a `Withdrawal` event. | ||
|
|
||
| The ABI for this event is: | ||
|
|
||
| ```solidity | ||
| event Withdrawal( | ||
| uint256 indexed ticketHash, | ||
| address sender, | ||
| address ticketOwner, | ||
| bytes22 receiver, | ||
| bytes22 proxy, | ||
| uint256 amount, | ||
| uint256 withdrawalId | ||
| ); | ||
| ``` | ||
|
|
||
| The topics for this event are: | ||
|
|
||
| Field | Type | Description | ||
| --- | --- | --- | ||
| Signature | `keccak256` | `Withdrawal(uint256)` | ||
| `ticketHash` | uint256 | The hash of the ticket that represents the transferred tokens, computed as `keccak256(L1 ticketer + content)` | ||
|
|
||
| The payload includes these fields: | ||
|
|
||
| Field | Type | Description | ||
| --- | --- | --- | ||
| `sender` | address | The Etherlink address that is withdrawing the tokens | ||
| `ticketOwner` | address | The ERC-20 proxy contract that manages the tokens | ||
| `receiver` | bytes22 | The layer 1 address that receives the tokens | ||
| `proxy` | bytes22 | The address of the token bridge helper contract | ||
| `amount` | uint256 | The amount of tokens | ||
| `withdrawalId` | uint256 | An internal ID for the withdrawal | ||
|
|
||
| ### `FastFaWithdrawal` event | ||
|
|
||
| When an account initiates a fast withdrawal, the FA bridging precompiled contract (`0xff0...0002`) emits a `FastFaWithdrawal` event. | ||
|
|
||
| The ABI for this event is: | ||
|
|
||
| ```solidity | ||
| event FastFaWithdrawal( | ||
| uint256 indexed ticketHash, | ||
| address sender, | ||
| address ticketOwner, | ||
| bytes22 receiver, | ||
| bytes22 proxy, | ||
| uint256 amount, | ||
| uint256 withdrawalId, | ||
| uint256 timestamp, | ||
| bytes payload | ||
| ); | ||
| ``` | ||
|
|
||
| The topics for this event are: | ||
|
|
||
| Field | Type | Description | ||
| --- | --- | --- | ||
| Signature | `keccak256` | `FastFaWithdrawal(uint256)` | ||
| `ticketHash` | uint256 | The hash of the ticket that represents the transferred tokens, computed as `keccak256(L1 ticketer + content)` | ||
|
|
||
| The payload includes these fields: | ||
|
|
||
| Field | Type | Description | ||
| --- | --- | --- | ||
| `sender` | address | The Etherlink address that is withdrawing the tokens | ||
| `ticketOwner` | address | The ERC-20 proxy contract that manages the tokens | ||
| `receiver` | bytes22 | The layer 1 address that receives the tokens | ||
| `proxy` | bytes22 | The address of the token bridge helper contract | ||
| `amount` | uint256 | The amount of tokens | ||
| `withdrawalId` | uint256 | An internal ID for the withdrawal | ||
| `timestamp` | uint256 | The timestamp of the block that includes the fast withdrawal request | ||
| `payload` | bytes | Information about the fast withdrawal to forward to the fast withdrawal contact | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess these are preceded by the ticket hash and proxy address, right? (as I see 7 fields in the list above, instead of 5). If so, can we be more explicit?