You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to have a contract written , tested and ready to "deploy" to ContractId 0x000...000.
Assuming this contract will NOT be upgradeable, we'll need to decide whether we want to make the base asset flash-mintable or flash-loanable.
Otherwise, it will probably look like a fairly standard Fungibl token contract, with mint(), burn(), and transfer() functionality.
Access control will be critical, and we should probably have a spec for the base asset before trying to write the contract.
Flash-minting the base asset would be a nice trick. I don't think there's any reason not to support it, if we're confident in the implementation. (Note: the same could be said of the bridge fungible token )
I think we'd want to use the lowest-level API for that, which will only really become ergonomic to use once the SDK/tooling catches up, but is the most flexible in terms of not locking in anything that we might want to change later (see: the other functions in the low_level_call library). E.g we wouldn't even be enshrining the layout of the payload.
After discussing this with @pixelcircuits, the only thing this contract would be used for that I can currently think of is flash-minting/flash loans.
For all other usage of the base assets on Fuel, the tokens will exist only as bridged tokens (UTXo's) and this is handled by the protocol. So for "normal" usage, there will never be a need to mint/burn tokens.
Given the number of high-priority tasks that need to be done before mainnet, this contract could be introduced at a later time, in between POA and POS mode.
We need to have a contract written , tested and ready to "deploy" to
ContractId
0x000...000.Assuming this contract will NOT be upgradeable, we'll need to decide whether we want to make the base asset flash-mintable or flash-loanable.
Otherwise, it will probably look like a fairly standard Fungibl token contract, with
mint()
,burn()
, andtransfer()
functionality.Access control will be critical, and we should probably have a spec for the base asset before trying to write the contract.
cc @adlerjohn @simonr0204
The text was updated successfully, but these errors were encountered: