ERC777PresetFixedSupplyUpgradeablewhich provides OOTB standard ERC-777 functionality, namely operators to send tokens on behalf of another address—contract or regular account—and send/receive hooks to offer holders more control over their tokens.
SafeMathfunction to eliminate overflow errors. In the latest versions of Solidity, this gas-intensive operation simply isn't necessary anymore. And it means the temporary assignment in memory of
xprior to calling
subis also not necessary because the subtraction assignment operator can be used which is already optimal without the optimiser running on it further (which, as noted earlier, the RFI-based tokens don't even enable). So, this is what Schnoodle does instead:
_tOwned), and their reflected balance (
_rOwned). Neo's code strips away this complexity and instead leverages the existing provisions of the OpenZeppelin Contracts, namely the
ERC777Upgradeablecontract, to store all reflected balances.
balanceOffunctions, as thus:
amountis the amount of tokens being transferred whether the main or eleemosynary amount.
reflectedTotalSupplyis exactly that, but is effectively reduced on every transfer due to the burn.
totalSupplyremains constant as this represents the total SNOOD supply and is never reduced by the algorithm.
chargeRaterepresents the fee or donation charged for every transfer.
reflectedBalanceis the reflected balance of the address requested, as stored in the OpenZeppelin
SchnoodleTimelockcontract which is based on the tried-and-tested OpenZeppelin
TokenTimelockcontract. We hope by that time, there will be enough LPs to make the pool liquid enough for this to no longer be a concern. But if that's not the case, then we will of course lock our liquidity for another 6 months before the first 6 months lapses. And we will advertise this on all our channels including Telegram.
SchnoodleTimelockcontracts as required. These are known as minimal proxy contracts, or simply "clones", and are created through our
SchnoodleTimelockFactorycontract. As well as liquidity, we use these clones to lock the community reserves. This is an extremely gas-efficient method to create timelock contracts, which means we can lock tokens from the community pool later for individuals such as influencers who will help promote Schnoodle.
TransparentUpgradeableProxycontract, Schnoodle leverages the EIP-1967 Transparent Proxy pattern whereby a proxy contract is deployed. All interactions with Schnoodle go via this proxy, and if you view the proxy contract on Etherscan, you will notice two additional buttons on the Contract tab: Read as Proxy and Write as Proxy. These show the ABI of the underlying implementation contract (
Schnoodle) to which there is a link on the respective 'proxy' pages.
Schnoodlesmart contract can be upgraded in the future without changing the contract address because the proxy contract never changes. And due to the immutability of blockchain, the existing state can never be changed. We can only add new state.
ProxyAdmincontract. It is through this contract that all upgrades are conducted.
SchnoodleGovernancesmart contract which implements the ERC-165 standard.
TimelockControllerbase contract. During deployment of
SchnoodleGovernance, ownership of both the
Schnoodlecontract and the aforementioned
ProxyAdmincontract is transferred to it so that any changes or upgrades to the
Schnoodlecontract are delayed by a minimum time period so that holders can view the change/upgrade on the blockchain before it becomes effective. If holders don't like it or find a problem with it, they can take action straight away, or we can cancel the change/upgrade.
Exec Transactionand view its logs. If the logs include an event called
CallScheduled, then this is a scheduled contract interaction. The next steps outline how to decode this log.
targetfield an address. This is the contract being interacted with, and will resolve to the
ProxyAdmincontract for upgrades.
datafield three values separated by
000000000000000000000000(24 zeros), as thus:
upgradefunction being called and will show as
TransparentUpgradeableProxycontract being upgraded.
CallExecutedevent in the Gnosis Safe address logs.
SchnoodleGovernanceis deployed with the proposer and executor of actions on the contract set to our Gnosis Safe address where multiple signatory wallets are required for signing contract interactions such as upgrades. This protects you the holder against unilateral decisions or, even worse, leaked private keys like what happened with PAID Network.
Schnoodlesmart contract is deployed to the Ethereum blockchain along with three other contracts:
TransparentUpgradeableProxy: All interaction with Schnoodle is done via this proxy.
ProxyAdmin: Any upgrades can only be done via this contract which is owned by...
SchnoodleGovernance: This executes 'upgrade' calls on ProxyAdmin but only after a minimum time period has elapsed (set in the contract). And this contract can only be interacted with by our Gnosis Safe address.
Schnoodlecontract version (say,
SchnoodleV2) is prepared with the proxy (this means it's not yet active, but ready to activate).
SchnoodleGovernance, the upgrade is executed at the Gnosis Safe address, again requiring sign-off by the multi-signatory wallets, and broadcast to the blockchain.
ProxyAdmin), which can be done by anyone including you, can now be made via Snapshot where off-chain votes are gathered. Once voting has closed, a question is placed on Reality.eth asking if the proposal passed. This question is posed for 24 hours before the outcome may be finalised. The question may be answered by anyone with the placement of a bond in ETH.
SchnoodleGovernancewhich is the owner of
ProxyAdminwhich can therefore only be interacted with by our Gnosis Safe account).