This PR introduces a revision of the overall Swaplace v0.1 contracts and opens the window for two new features as we reach v0.2.
The functionalities, specs, naming, docs, and architecture were deeply examined. This is by far an audit, especially because of the introduction of new features.
Native Ehter transfer will require the addition of 2 new variables to the architecture and hence, will change a lot of aspects of the dApp and the code. Increasing the size of the config (uint256) variable from 2 to 4 elements. This will only increase the math cost of the blockchain which is very cheap.
ERC1155 support was fully compatible with the dApp and without increasing no more than 100 gas units per acceptSwap(), we managed to implement such support with only one drawback: we cannot use token ids and amounts that reach enormous amounts. The limit for tokenId and tokenAmount is set at:
1,329,227,995,784,916,000,000,000,000,000,000,000. It will be compatible with more than 99% of the projects out there. But a few that use hashed integers for their IDs will be incompatible (hash = keccak256(data)).
Tests
This version was merely tested and it's still in the production stage. The tests surrounding these two features will be available as issues and delegated to the community. The rewards for round 2 were extended because the dApp overconsumed the core team time and since that was unfair, new issues will take place and they will be fully focused on smart contracts. Stay tunned for the next weeks!!
Swaplace v0.2
This PR introduces a revision of the overall Swaplace v0.1 contracts and opens the window for two new features as we reach v0.2. The functionalities, specs, naming, docs, and architecture were deeply examined. This is by far an audit, especially because of the introduction of new features.
Features
The features are well documented within the contract itself, but I will clarify over time. The following issue explains precisely how the native ether swap will work: https://github.com/blockful-io/swaplace-subgraph/issues/32
Backwards compatibility and Gas costs
Native Ehter transfer will require the addition of 2 new variables to the architecture and hence, will change a lot of aspects of the dApp and the code. Increasing the size of the config (uint256) variable from 2 to 4 elements. This will only increase the math cost of the blockchain which is very cheap.
ERC1155 support was fully compatible with the dApp and without increasing no more than 100 gas units per
acceptSwap(), we managed to implement such support with only one drawback: we cannot use token ids and amounts that reach enormous amounts. The limit fortokenIdandtokenAmountis set at:1,329,227,995,784,916,000,000,000,000,000,000,000. It will be compatible with more than 99% of the projects out there. But a few that use hashed integers for their IDs will be incompatible (hash = keccak256(data)).Tests
This version was merely tested and it's still in the production stage. The tests surrounding these two features will be available as issues and delegated to the community. The rewards for round 2 were extended because the dApp overconsumed the core team time and since that was unfair, new issues will take place and they will be fully focused on smart contracts. Stay tunned for the next weeks!!