Reference information for FA bridging calls and events - #367
Reference information for FA bridging calls and events#367timothymcmackin wants to merge 10 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
b8c15d8 to
3480309
Compare
2b2bec3 to
f73117f
Compare
780d2b1 to
4d205fc
Compare
4d205fc to
1f96ddc
Compare
11ad135 to
091c992
Compare
091c992 to
72f4eb3
Compare
| Field | Type | Description | ||
| --- | --- | --- | ||
| `ticketOwner` | address | The ERC-20 proxy contract that manages the tokens | ||
| `receiver` | address | The ERC-20 proxy contract that manages the tokens (a duplicate of the `ticketOwner` field) |
There was a problem hiding this comment.
This is untrue, it is the etherlink account receiving the FA deposit tokens
There was a problem hiding this comment.
Rewritten the "receiver" field as you suggested; also mentioned that ticketOwner may be the receiver in some cases, is that correct?
There was a problem hiding this comment.
Rewritten the "receiver" field as you suggested
Looks good
also mentioned that ticketOwner may be the receiver in some cases, is that correct?
Yes correct, but this is more of a fallback mechanism, not something that's meant to be used atm, so I'm not sure we should mention it
|
|
||
| Field | Type | Description | ||
| --- | --- | --- | ||
| `ticketOwner` | address | The ERC-20 proxy contract that manages the tokens |
There was a problem hiding this comment.
ticketOwner can sometimes be the receiver, but imho this is an implem detail and shouldn't be mentionned, I'll let you be the judge of it
There was a problem hiding this comment.
I'll add "or, in some cases, the account receiving the deposited tokens"
bcee516 to
523b649
Compare
| 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: |
There was a problem hiding this comment.
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?
| 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: | |
| 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 (preceded by the two topics fields: ticket hash and proxy address, detailed later): |
| Field | Type | Description | ||
| --- | --- | --- | ||
| `ticketOwner` | address | The ERC-20 proxy contract that manages the tokens | ||
| `receiver` | address | The ERC-20 proxy contract that manages the tokens (a duplicate of the `ticketOwner` field) |
There was a problem hiding this comment.
Rewritten the "receiver" field as you suggested; also mentioned that ticketOwner may be the receiver in some cases, is that correct?
|
|
||
| Field | Type | Description | ||
| --- | --- | --- | ||
| `nonce` | uint256 | The global counter for the transaction |
There was a problem hiding this comment.
Accross the doc we use nonce and depositID, I understand it was probably taken from the code and is also bad naming on our end, but now that I'm seeing it I find it misleading, we probably want to use deposit id only to avoid referencing the nonce, which is already asociated to another concept in ethereum.
Also here "The global counter for the transaction" is false, its the deposit id.
Provide more detailed information about how the FA bridge works. I took information about the events from
etherlink/kernel_latest/revm/contracts/fa_bridge.solbut I'm not sure if I've got each field explained clearly.