Skip to content

Reference information for FA bridging calls and events - #367

Open
timothymcmackin wants to merge 10 commits into
mainfrom
fa-bridge-events
Open

Reference information for FA bridging calls and events#367
timothymcmackin wants to merge 10 commits into
mainfrom
fa-bridge-events

Conversation

@timothymcmackin

@timothymcmackin timothymcmackin commented Sep 18, 2025

Copy link
Copy Markdown
Collaborator

Provide more detailed information about how the FA bridge works. I took information about the events from etherlink/kernel_latest/revm/contracts/fa_bridge.sol but I'm not sure if I've got each field explained clearly.

@timothymcmackin timothymcmackin self-assigned this Sep 18, 2025
@vercel

vercel Bot commented Sep 18, 2025

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
docs-etherlink Ready Ready Preview, Comment Jan 30, 2026 4:43pm

Request Review

Comment thread docs/bridging/bridging-fa-how.md Outdated
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)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is untrue, it is the etherlink account receiving the FA deposit tokens

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rewritten the "receiver" field as you suggested; also mentioned that ticketOwner may be the receiver in some cases, is that correct?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread docs/bridging/bridging-fa-how.md Outdated
Comment thread docs/bridging/bridging-fa-how.md Outdated

Field | Type | Description
--- | --- | ---
`ticketOwner` | address | The ERC-20 proxy contract that manages the tokens

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add "or, in some cases, the account receiving the deposited tokens"

Comment thread docs/bridging/bridging-fa-how.md Outdated
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:

Copy link
Copy Markdown
Collaborator

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?

Suggested change
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):

Comment thread docs/bridging/bridging-fa-how.md Outdated
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)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rewritten the "receiver" field as you suggested; also mentioned that ticketOwner may be the receiver in some cases, is that correct?

Comment thread docs/bridging/bridging-fa-how.md Outdated
Comment thread docs/bridging/bridging-fa-how.md Outdated
@NicNomadic NicNomadic removed their assignment Apr 7, 2026

Field | Type | Description
--- | --- | ---
`nonce` | uint256 | The global counter for the transaction

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants