Skip to content

add fee model clarifications and link to relevant EVM Bridge ADR #364

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.

Sign up for GitHub

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

Merged
joshuahannan merged 1 commit into from
Mar 20, 2026
Merged

add fee model clarifications and link to relevant EVM Bridge ADR #364

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 13 additions & 1 deletion application/20231222-evm-vm-bridge.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -298,7 +298,9 @@ following sections outline an NFT bridge path for each case.
> :information_source: **Fee model:** Bridge fees are only charged when an operation causes the bridge account to store
> an asset long-term (e.g., escrowing a Cadence NFT or holding an ERC721 in the bridge's COA). Operations that release
> assets from existing escrow or burn assets do **not** incur a bridge fee, because they do not add to the bridge
> account's storage. Onboarding operations always incur a separate flat onboarding fee regardless of direction.
> account's storage. Onboarding operations always incur a separate flat onboarding fee regardless of direction. For the
> full rationale and handler-by-handler breakdown, see
> [ADR-0001](https://github.com/onflow/flow-evm-bridge/blob/main/docs/adr/ADR-0001-nft-bridge-fee-model.md).

> :information_source: A note about bridge "onboarding" - assets moving from one VM to another must at minimum have
> contracts defining them in their target VM. These contracts must be deployed in a transaction preceding the movement
Expand Down Expand Up @@ -382,6 +384,13 @@ following sections outline an NFT bridge path for each case.

*Mint/Unlock in Cadence & Transfer in EVM*

> :information_source: The steps below describe the **default path** for EVM-native NFTs without a cross-VM
> registration. For projects registered via `registerCrossVMNFT` (FLIP 318), the bridge dispatches to a dedicated
> cross-VM handler (`handleEVMNativeCrossVMNFTFromEVM`) that does not add to the bridge's Cadence storage. No bridge
> fee is charged on that path — see
> [ADR-0001](https://github.com/onflow/flow-evm-bridge/blob/main/docs/adr/ADR-0001-nft-bridge-fee-model.md) for
> details.

1. Pre-flight checks: Assert the type is supported and has been onboarded, and fee provider can cover the bridge fee
2. Get the requested type's associated EVM contract address
3. Assert the caller is the requested ERC721 token owner or approved
Expand All @@ -400,6 +409,9 @@ following sections outline an NFT bridge path for each case.

*Lock in Flow & Transfer in EVM*

> :information_source: No bridge fee is charged for this operation. The bridge-deployed Cadence NFT is burned (step 6)
> rather than escrowed, so no new storage is added to the bridge account.

1. Assert the asset is either an NFT or FT & has been onboarded (it will be by construction)
2. Determine if asset is FT or NFT
- Check if resource is an instance of FT.Vault or NFT.NFT (excluding overlapping instances, at least for POC)
Expand Down
Loading