# Override Transfer Functionality

**URL:** <https://forum.fuel.network/t/override-transfer-functionality/7152>\
**Category:** Sway\
**Created:** [November 30, 2024, 1:35pm UTC](https://forum.fuel.network/t/override-transfer-functionality/7152 "2024-11-30T13:35:48Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![SimpleMan](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.fuel.network/simpleman/32/3763_2.png) [@SimpleMan](https://forum.fuel.network/u/SimpleMan)\
**Post date:** [November 30, 2024, 1:35pm UTC](https://forum.fuel.network/t/override-transfer-functionality/7152/1 "2024-11-30T13:35:48Z")

</div>

Let’s say I have a multi-asset minter contract, before a certain condition hits, I don’t want the assets to be transferable, to other users or contracts. I would still want the asset to be minted and burned. What are my options?

---

<div class="post-metadata">

**Author:** ![naz3eh](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.fuel.network/naz3eh/32/2025_2.png) [@naz3eh](https://forum.fuel.network/u/naz3eh)\
**Post date:** [December 2, 2024, 9:06am UTC](https://forum.fuel.network/t/override-transfer-functionality/7152/2 "2024-12-02T09:06:18Z")

</div>

You can use predicates and scripts for that. You can specify that condition in the predicate and it will release funds only if the condition is met. However, in this scenario, predicates will store the funds and not the user.

---

<div class="post-metadata">

**Author:** ![SimpleMan](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.fuel.network/simpleman/32/3763_2.png) [@SimpleMan](https://forum.fuel.network/u/SimpleMan)\
**Post date:** [December 2, 2024, 10:44am UTC](https://forum.fuel.network/t/override-transfer-functionality/7152/3 "2024-12-02T10:44:25Z")

</div>

It becomes a UX issue for users IMO, might as well not have the assets minted, and have a claim option, again not great from a user perspective. Some context:

Currently working on a launchpad that issues tokens over a bonding curve, once the bonding curve is completed I want to migrate the liquidity to a DEX. The issue happens if someone goes ahead and makes a skewed pool on the DEX before the bonding curve is completed, forcing an un-optimal migration. If I can block transfers to the DEX address before bonding curve is completed that would be great. Having a standard transfers() function is limiting.

---

<div class="post-metadata">

**Author:** ![Bobby5424](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.fuel.network/bobby5424/32/3839_2.png) [@Bobby5424](https://forum.fuel.network/u/Bobby5424)\
**Post date:** [December 11, 2024, 5:37pm UTC](https://forum.fuel.network/t/override-transfer-functionality/7152/4 "2024-12-11T17:37:24Z")

</div>

Blocking transfers before a certain condition is met is tricky, especially from a UX perspective. A predicate could work, but it may feel limiting for users. Perhaps implementing a time-lock or migration safeguard that restricts transfers until the bonding curve is completed could be a more seamless solution for users while maintaining control over the liquidity migration.

---

<div class="post-metadata">

**Author:** ![hernando07](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.fuel.network/hernando07/32/3830_2.png) [@hernando07](https://forum.fuel.network/u/hernando07)\
**Post date:** [December 11, 2024, 9:02pm UTC](https://forum.fuel.network/t/override-transfer-functionality/7152/5 "2024-12-11T21:02:03Z")

</div>

Consider a dynamic `transfer()` function that checks bonding curve completion before authorizing transfers. Alternatively, use a whitelist for allowed addresses during the bonding phase or a conditional escrow to “soft-lock” tokens for UX while blocking unauthorized transfers.

---

<div class="post-metadata">

**Author:** ![SimpleMan](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.fuel.network/simpleman/32/3763_2.png) [@SimpleMan](https://forum.fuel.network/u/SimpleMan)\
**Post date:** [December 12, 2024, 3:37pm UTC](https://forum.fuel.network/t/override-transfer-functionality/7152/6 "2024-12-12T15:37:43Z")

</div>

`transfer()` function cannot be changed as it’s native for all Fuel assets.

---

<div class="post-metadata">

**Author:** ![SimpleMan](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.fuel.network/simpleman/32/3763_2.png) [@SimpleMan](https://forum.fuel.network/u/SimpleMan)\
**Post date:** [December 12, 2024, 3:38pm UTC](https://forum.fuel.network/t/override-transfer-functionality/7152/7 "2024-12-12T15:38:31Z")

</div>

Closing, going with the assign balances + claim later option as it’s the simplest. Feature request would be to have at least a pausing function on token transfers.

---

<div class="post-metadata">

**Author:** ![jackquelinevtuto3](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.fuel.network/jackquelinevtuto3/32/3853_2.png) [@jackquelinevtuto3](https://forum.fuel.network/u/jackquelinevtuto3)\
**Post date:** [December 16, 2024, 11:48pm UTC](https://forum.fuel.network/t/override-transfer-functionality/7152/8 "2024-12-16T23:48:19Z")

</div>

I understand your challenge. The simplest solution might be to use a claim mechanism, as you mentioned — it would definitely reduce complexity for users. In the case of restricting transfers until the bonding curve is completed, you could implement some form of “freeze” on the assets using a temporary pause on transactions, so no one can send them to the DEX before the liquidity migration is done. This would minimize the risk of someone skewing the market, while still allowing you to work with tokens based on minting and burning mechanisms. Of course, this restriction may not be popular with everyone, but in your case, it seems like the best option for maintaining control over the process.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex022/uploads/fuel/original/2X/5/57d5a345cc15a64b636e0d56e042857f8a0e80b1.png) [@system](https://forum.fuel.network/u/system)\
**Post date:** [January 29, 2025, 8:44pm UTC](https://forum.fuel.network/t/override-transfer-functionality/7152/9 "2025-01-29T20:44:11Z")

</div>

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.
