As discussed in #46, `CollectibleV1` is not a good name for this
contract as we don't want versioning in the naming. To align with other
contracts in this repository, we're renaming this contract to
`CommunityERC721`.
BREAKING CHANGE: Any references to `CollectibleV1` must be replaced with
`CommunityERC721`
Closes#46
* add CommunityVault contract
* use named import
* test vault transfer functions for erc20 and erc721
* fix camel case test name
* update format with latest version of forge
This commit changes a few token properties to be `immutable` as this
reduces gas costs even further.
This was reported by Slither.
A gas report with changes in gas cost is attached.
While the underlying factories emit a `CreateToken` event, there was a
request to have specific deployment events for each token emitted by the
deployer.
This commit introduces custom errors for `BaseToken` and
`CommunityERC20` to reduce the gas costs in revert cases. Using
`require()` with a string error message requires every character of the
message to be store in memory which costs more gas than a fixed sized
error selector. Hence, it's recommended to use custom errors instead.
A gas snapshot is attached in this commit to show the improved gas
costs.
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.
This commit does a couple of things:
- moves the project to our foundry template structure and workflows
- removes hardhat usage and dependencies
- removes unused contracts
- ports existing JS tests to foundry tests
- adds additional tests for `CommunityERC20` contract
- Introduces deploy scripts written in solidity which are also covered
by tests
The projects can now be build and tests with:
```
$ forge build
```
```
$ forge test
```
Test deployments can be done via
```
$ forge script script/DeployOwnerToken.sol
```
r4bbit
0xb337r007
Cuteivist
0xb337r007