Fast transfers from UTXO chains #417

kiseln · 2025-09-12T12:34:24Z

No description provided.

near/omni-bridge/src/lib.rs

karim-en · 2025-09-23T13:54:37Z

near/omni-bridge/src/lib.rs

+        // Verify this is indeed a UTXO chain token
+        let _ = self
+            .get_utxo_chain_by_token(&token_id)
+            .sdk_expect("ERR_TOKEN_NOT_FROM_UTXO_CHAIN");


The utxo_transfer_msg contains the Omni token address:

This address can be used to optimize the get_utxo_chain_by_token call.

We have to verify that the token address in the msg is correct to avoid vulnerabilities

This is actually a mistake, I believe we can remove the OmniAddress. Sender doesn't have to know what the address on Near is

karim-en · 2025-09-23T13:57:30Z

near/omni-bridge/src/lib.rs

+                    fee: utxo_transfer_msg.fee,
+                    native_fee: U128(0),
+                },
+                sender: OmniAddress::Near(env::predecessor_account_id()), // TODO who is the sender?


For now, the UTXO connector address could be the sender.
Later we can consider to add the sender to the msg, this will be needed if external actions is needed to be done by the user (eg sign custom message using Zcash wallet like in near-intents)

karim-en · 2025-09-23T14:12:52Z

near/omni-bridge/src/lib.rs

-        if self.is_transfer_finalised(fast_transfer.transfer_id) {
-            env::panic_str("ERR_TRANSFER_ALREADY_FINALISED");
-        }
+        // if self.is_transfer_finalised(fast_transfer.transfer_id) {


This check should be done for both "to near" and "to other chain". The transaction can be delayed due to networks or chains issues, so we have to protect the relayer.

Brought it back 8449952. Two points:

It's convenient to have it at this level but there is a small chance of race condition because fast transfer will be executed in the next block (due to storage check)

We currently don't need to store UTXO transfer id because duplicates are checked on connector level. But we have to add it for this part of the code if we want extra protection

karim-en · 2025-09-23T14:13:56Z

near/omni-types/src/lib.rs


+#[near(serializers=[borsh, json])]
+#[derive(Debug, Clone)]
+pub enum UnifiedTransferId {


@frolvanya please look into this new structure if it fits the indexer requirements

karim-en · 2025-09-23T14:23:02Z

near/omni-bridge/src/lib.rs

+            return self
+                .send_tokens(token_id, status.relayer, amount, &String::new())
+                .into();
+        }
+
+        if let OmniAddress::Near(recipient) = utxo_transfer_msg.recipient {
+            // Fast transfer didn't happen so we send the user full amount including fee
+            return self
+                .send_tokens(token_id, recipient, amount, &utxo_transfer_msg.msg)
+                .into();


The send_tokens call isn't async, this mean that it's results affect the refund for the top ft_tranasfer_call.
For example if the msg is empty then the last promise will be ft_transfer with empty results.
Also there are edge cases for ft_transfer_call panics and returned values.
We have to cover all of that with tests.
Also it will be good to verify the storage deposit for the the recipient

If the call fails we are okay to refund the tokens.

Two questions to answer here are:

What happens if empty result is returned

Whether we can use ft_transfer_call return value. I believe here the answer is no because it will return used_amount while we want to return 0 in case of success

Is my understanding correct? If so, I'll add a callback to handle it

Added some changes here 2537719

Do we really need to validate storage for the recipient? If the transfer fails we would handle the refund properly

Do we really need to validate storage for the recipient? If the transfer fails we would handle the refund properly

Not really, depends on how you are going to handle the refund.
For example for the ft_transfer it is ok to refund if the receipt failed, but it isn't safe to refund if the ft_transfer_call failed.

And it isn't safe because of potential out of gas issue?

Yes, correct. We have 2 options here:

verify the storage deposit before the ft_transfer_call.

modify the token contract, so the ft_transfer_call will returns value instead of panic of the account isn't registered

Added ade99b2

olga24912 · 2025-09-25T13:26:20Z

near/omni-types/src/lib.rs

    pub fee: U128,
-    pub native_token_fee: U128,
-    pub msg: Option<String>,
+    pub msg: String,


Why msg not Option?

It's not option in InitTransferMessage either. We use empty strings

olga24912 · 2025-09-25T13:34:39Z

near/omni-bridge/src/lib.rs

            BridgeOnTransferMsg::FastFinTransfer(fast_fin_transfer_msg) => {
                self.fast_fin_transfer(token_id, amount, signer_id, fast_fin_transfer_msg)
            }
+            BridgeOnTransferMsg::UtxoTransfer(utxo_transfer_msg) => {


Suggested change

BridgeOnTransferMsg::UtxoTransfer(utxo_transfer_msg) => {

BridgeOnTransferMsg::TransferFromUtxo(utxo_transfer_msg) => {

What about a name like this? Otherwise, it seems like these arguments need to be passed when transferring to a UTXO.

Agreed yours is better. Also thinking about UtxoFinTransfer or FinTransferFromUtxo

near/omni-bridge/src/storage.rs

Fast transfers from UTXO chains

485862d

kiseln commented Sep 12, 2025

View reviewed changes

near/omni-bridge/src/lib.rs Outdated Show resolved Hide resolved

UTXO asset transfer to 3rd chain

a0e51cc

kiseln force-pushed the feat/fast-transfers-for-utxo branch from 81bffe2 to a0e51cc Compare September 12, 2025 15:14

kiseln commented Sep 12, 2025

View reviewed changes

near/omni-bridge/src/lib.rs Outdated Show resolved Hide resolved

Fix origin_tranfser_id flow

8738a5c

kiseln requested review from karim-en, frolvanya and olga24912 September 16, 2025 17:43

karim-en requested changes Sep 23, 2025

View reviewed changes

olga24912 requested changes Sep 25, 2025

View reviewed changes

kiseln added 4 commits September 26, 2025 16:09

Handle send_tokens callbacks

2537719

Correct storage cost estimation for UnifiedTransferId

6db44c2

Add storage check for utxo fin transfer

ade99b2

Bring back fast transfer finalized check

8449952

kiseln marked this pull request as ready for review September 29, 2025 12:32

	BridgeOnTransferMsg::UtxoTransfer(utxo_transfer_msg) => {
	BridgeOnTransferMsg::TransferFromUtxo(utxo_transfer_msg) => {

Fast transfers from UTXO chains #417

Are you sure you want to change the base?

Fast transfers from UTXO chains #417

Conversation

kiseln commented Sep 12, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

karim-en Sep 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

karim-en Sep 26, 2025 •

edited

Loading