NFT Bridge
Automated scanning of NFT contracts for potentially malicious code that could harm the bridge or its users.
Original chain contract deployment.
It replaces whitelisting.
Protects the bridge contract from direct interaction with NFT collection contracts
Distributes risk: all NFT collection contracts interact with no more than one blocking contract. If an NFT contract turns out to be malicious, it will not be allowed to interact with the bridge or other collection lockersю
Automatic deployment of the target contract - If the target contract doesn't exist, the bridge can automatically deploy it. In addition, the bridge automatically maps the source and target contracts, allowing tokens to flow from one to the other. Now any NFT owner can install a bridge without waiting for the NFT collection team to contact the XP.NETWORK team.
Royalties in the NFT Bridge
If there is no logic in the source smart contract that supports royalties, the target contract will not support royalties either. The royalty rate in the target contract is equal to the rate in the source contract.
Because the format of the address format of the royalty recipients in the original contract may not be compatible with the addresses of the royalty recipients in the target chain, a set of addresses is allocated to each chain that will receive royalties on behalf of the creators of the original NFT. Collection teams will be able to verify royalties on the respective chains from the addresses below and receive them from XP.NETWORK. Royalties from targeted contracts are remitted to collection creators twice a month.
Bridge Action ID
Following the principle of preventing duplicate assets as part of a layered security system, we ensure that assets are only available to users in one place at one time. For example, if an Ethereum-minted NFT connects to MultiversX, the Ethereum token is locked in the bridge contract. The only NFT available for users to transfer, trade, stake, etc. is on MultiversX.
Since different blockchains are asynchronous and unaware of each other's existence, the bridge fills this gap by passing its transaction or action identifiers to smart contracts that organize token contracts and off-chain validator oracles.
The bridge contract keeps track of all outgoing and incoming transactions. Outgoing transactions are incremented (actionId++;) each time users interact with the contract by calling its functions. The external transactions are stored in a mapping ensuring O(1) access complexity to prevent duplicate transactions.
Architecture and Bridge Flow
Prerequisites: Alice has an NFT in chain A, and she wants to bridge it to Bob's account in chain B. Here are the steps of the data transfer with Fee Oracle installed.
- Alice selects the NFT in the XP.NETWORK bridge user interface and signs the Transfer transaction.
- The user interface uses the TypeScript xpjs API library.
- The API library sends a request to a network of fee oracles, each of which listens to the APIs of various market aggregators.
- The oracle network estimates the average token price, signs it using elliptic cryptography, and returns the data to the API library.
- XPJS sends the signed transaction with the signed fee calculation.
- The bridge smart contract locks the selected NFT in its vault.
- The bridge contract emits an event with all necessary bridge data.
- The bridge validators unpack the event, package it into a transaction, sign it with FROST and send it to the target bridge contract.
- The bridge contract validates the signature, unpacks the data, and mints the wrapped NFT in an NFT contract for Bob.
