feat: implement `CommunityTokenDeployer` contract (#2)
This commit introduces the `CommunityTokenDeployer` contract discussed
in https://github.com/status-im/status-desktop/issues/11954.
The idea is that, instead of having accounts deploy `OwnerToken` and
`MasterToken` directly, they'd use a deployer contract instead, which
maintains a registry of known `OwnerToken` addresses, mapped to Status
community addresses.
The following changes have been made:
It was, and still is, a requirement that both, `OwnerToken` and
`MasterToken` are deployed within a single transaction, so that when
something goes wrong, we don't end up in an inconsistent state.
That's why `OwnerToken` used to instantiated `MasterToken` and required
all of its constructor arguments as well.
Unfortunately, this resulted in compilation issues in the context of the
newly introduce deployer contract, where there are too many function
arguments.
Because we now delegate deployment to a dedicated contract, we can
instantiate both `OwnerToken` and `MasterToken` in a single transaction,
without having `OwnerToken` being responsible to instantiate
`MasterToken`.
This fixes the compilation issues and simplifies the constructor of
`OwnerToken`.
The new `CommunityTokenDeployer` contract is now responsble for
deploying the aforementioned tokens and ensures that they are deployed
within a single transaction.
To deploy an `OwnerToken` and `MasterToken` accounts can now call
`CommunityDeloyerToken.deploy(TokenConfig, TokenConfig,
DeploymentSignature)`.
The `DeploymentSignature` uses `EIP712` structured type hash data to let
the contract verify that the deployer is allowed to deploy the contracts
on behalf of a community account.
2023-09-19 09:39:55 +00:00
|
|
|
// SPDX-License-Identifier: UNLICENSED
|
|
|
|
pragma solidity ^0.8.17;
|
|
|
|
|
|
|
|
import { BaseTokenFactory } from "./BaseTokenFactory.sol";
|
|
|
|
import { MasterToken } from "../tokens/MasterToken.sol";
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @title CommunityMasterTokenFactory contract
|
|
|
|
* @author 0x-r4bbit
|
|
|
|
*
|
|
|
|
* @notice This contract creates instances of `MasterToken`.
|
|
|
|
* @dev This contract inherits `BaseTokenFactory` to get access to
|
|
|
|
* shared modifiers and other functions.
|
|
|
|
*/
|
|
|
|
contract CommunityMasterTokenFactory is BaseTokenFactory {
|
|
|
|
error CommunityMasterTokenFactory_InvalidOwnerTokenAddress();
|
|
|
|
|
|
|
|
event CreateToken(address indexed);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @notice Creates an instance of `MasterToken`.
|
|
|
|
* @dev Only the token deployer contract can call this function.
|
|
|
|
* @dev Emits a {CreateToken} event.
|
|
|
|
* @param _name The name of the `MasterToken`.
|
|
|
|
* @param _symbol The symbol of the `MasterToken`.
|
|
|
|
* @param _baseURI The base token URI of the `MasterToken`.
|
|
|
|
* @param _ownerToken The address of the `OwnerToken`.
|
|
|
|
* @return address The address of the created `MasterToken` instance.
|
|
|
|
*/
|
|
|
|
function create(
|
|
|
|
string calldata _name,
|
|
|
|
string calldata _symbol,
|
|
|
|
string calldata _baseURI,
|
|
|
|
address _ownerToken,
|
|
|
|
bytes memory
|
|
|
|
)
|
|
|
|
external
|
|
|
|
onlyTokenDeployer
|
|
|
|
onlyValidTokenMetadata(_name, _symbol, _baseURI)
|
|
|
|
returns (address)
|
|
|
|
{
|
|
|
|
if (_ownerToken == address(0)) {
|
|
|
|
revert CommunityMasterTokenFactory_InvalidOwnerTokenAddress();
|
|
|
|
}
|
|
|
|
|
2023-12-12 22:10:27 +00:00
|
|
|
MasterToken masterToken = new MasterToken(_name, _symbol, _baseURI, _ownerToken);
|
feat: implement `CommunityTokenDeployer` contract (#2)
This commit introduces the `CommunityTokenDeployer` contract discussed
in https://github.com/status-im/status-desktop/issues/11954.
The idea is that, instead of having accounts deploy `OwnerToken` and
`MasterToken` directly, they'd use a deployer contract instead, which
maintains a registry of known `OwnerToken` addresses, mapped to Status
community addresses.
The following changes have been made:
It was, and still is, a requirement that both, `OwnerToken` and
`MasterToken` are deployed within a single transaction, so that when
something goes wrong, we don't end up in an inconsistent state.
That's why `OwnerToken` used to instantiated `MasterToken` and required
all of its constructor arguments as well.
Unfortunately, this resulted in compilation issues in the context of the
newly introduce deployer contract, where there are too many function
arguments.
Because we now delegate deployment to a dedicated contract, we can
instantiate both `OwnerToken` and `MasterToken` in a single transaction,
without having `OwnerToken` being responsible to instantiate
`MasterToken`.
This fixes the compilation issues and simplifies the constructor of
`OwnerToken`.
The new `CommunityTokenDeployer` contract is now responsble for
deploying the aforementioned tokens and ensures that they are deployed
within a single transaction.
To deploy an `OwnerToken` and `MasterToken` accounts can now call
`CommunityDeloyerToken.deploy(TokenConfig, TokenConfig,
DeploymentSignature)`.
The `DeploymentSignature` uses `EIP712` structured type hash data to let
the contract verify that the deployer is allowed to deploy the contracts
on behalf of a community account.
2023-09-19 09:39:55 +00:00
|
|
|
emit CreateToken(address(masterToken));
|
|
|
|
return address(masterToken);
|
|
|
|
}
|
|
|
|
}
|