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?
3 Likes
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.
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.
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.
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.
transfer() function cannot be changed as it’s native for all Fuel assets.
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.
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.