Needing of Contract Creation Instructions

Hi guys,

I have been searching around and reading the documents of the sway language, but I realize there is a missing of contract creation, such instructions have been heavily used in solidity smart contract programming, e.g [Uniswap V2 Factory Contract] β€” deploy β†’ [Pool Contract]

 function createPair(address tokenA, address tokenB) external returns (address pair) {
        require(tokenA != tokenB, 'UniswapV2: IDENTICAL_ADDRESSES');
        (address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
        require(token0 != address(0), 'UniswapV2: ZERO_ADDRESS');
        require(getPair[token0][token1] == address(0), 'UniswapV2: PAIR_EXISTS'); // single check is sufficient
        bytes memory bytecode = type(UniswapV2Pair).creationCode;
        bytes32 salt = keccak256(abi.encodePacked(token0, token1));
        assembly {
            pair := create2(0, add(bytecode, 32), mload(bytecode), salt)
        IUniswapV2Pair(pair).initialize(token0, token1);
        getPair[token0][token1] = pair;
        getPair[token1][token0] = pair; // populate mapping in the reverse direction
        emit PairCreated(token0, token1, pair, allPairs.length);

1 Like

All transactions on Fuel are either Script or ContractCreate transactions. Thus, a script can not create a contract.

This is a deliberate design choice, as this is a mechanism that is not needed in the FuelVM. Since contract IDs (addresses) are deterministic by design, there is no need for a CREATE2 style opcode. In addition, the β€œdynamic” creation of contracts has implications for the efficiency of fraud proofs over transaction execution, which is a further reason for its exclusion.

The primary design goal for a factory pattern can be achieved on Fuel by specifying a bytecode root which an implementation must match. For example, equivalent functionality to the snippet provided can be found in our implementation of a Uniswap v2-style AMM, where exchange contracts are registered with the central AMM contract using this mechanism.


Hi Simon,

Thank you so much for your rapid reply and knowledgeable feedback. I still have some questions about the needing for CREATE2 style opcode. Not sure if I understand it correctly:

  1. tx on Fuel is either Script or ContractCreate, meaning a contract address cannot send a tx for ContractCreate ?

  2. In terms of the needing for the feature, the contract address is deterministic however I think for a lot of applications, there is still a need for decentralized created a child contract from a factory contract such as a multisig wallet, the implementation in AMM makes a single tx for CREATE2 into a deploy + register pool (2tx) seems not too user-friendly

Thank you again for your reply.

1 Like

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