Seasonal Tokens

[seasonaltokens]

Audit request

There are four proof-of-work mineable ERC-20 tokens. Each token halves its rate of production every 3 years. The interval between the halving of each token and the next is 9 months. The mining rewards can be batched to reduce gas costs.

Source code

https://github.com/seasonaltokens/seasonaltokens

commit: 0be82284de6484d5adee25f8f9eb8f38d725ecf6

Disclosure policy

Standard disclosure policy is fine.

Contact information (optional)

admin at seasonaltokens.org

Platform

ETH

[seasonaltokens]

Estimated payment in ETH was sent to the specified Treasury Address: 0x74682Fc32007aF0b6118F259cBe7bCCC21641600

txn hash: 0x15a9db821abe388953207cfa4858d12c14ddd64fac5ee1b16e4a0b0254eab447

[yuriy77k]

Seasonal Tokens Security Audit Report

1. Summary

Seasonal Tokens smart contract security audit report performed by Callisto Security Audit Department

2. In scope

Commit 0be82284de6484d5adee25f8f9eb8f38d725ecf6

• ./interfaces/ERC20.sol

• ./interfaces/ERC918.sol

• ./interfaces/Owned.sol

• ./interfaces/ApproveAndCallFallBack.sol

• ./contracts/AutumnToken.sol

• ./contracts/SpringToken.sol

• ./contracts/SummerToken.sol

• ./contracts/WinterToken.sol

2.1. Excluded

• ./contracts/TestSpringToken.sol

3. Findings

In total, 0 issues were reported, including:

• 0 high severity issues.

• 0 medium severity issues.

• 0 low severity issues.

In total, 3 notes were reported, including:

• 3 notes.

• 0 owner privileges.

No critical security issues were found.

3.1. The constructor should not have onlyOwner modifier

Severity: note

Description

The constructor runs once on contract deployment, at the same time the deployer assigned as owner. So onlyOwner modifier has no sense in this case.

Also, revert contract deployment based on preset variable has no sense.

This applies to all contracts for Seasonal Tokens (SpringToken, SummerToken, AutumnToken, WinterToken).

Recommendation

Remove onlyOwner modifier and revert.

3.2. Duplicate functions

Severity: note

Description

The functions getChallengeNumber() and getMiningTarget() returns value of appropriate variables.
But the variables challengeNumber and miningTarget declared as public therefore compiler will automatically create the getter function for it.

This applies to all contracts for Seasonal Tokens (SpringToken, SummerToken, AutumnToken, WinterToken).

Recommendation

Remove functions getChallengeNumber() and getMiningTarget() or declare challengeNumber and miningTarget as private.

3.3. The totalSupply does not reflect the real total supply of tokens

Severity: note

Description

The function totalSupply() returns constant TOTAL_SUPPLY that does not reflect real total amount of tokens.

This applies to all contracts for Seasonal Tokens (SpringToken, SummerToken, AutumnToken, WinterToken).

Recommendation

Return in function totalSupply() the tokensMinted value instead of TOTAL_SUPPLY.

4. Security practices

• Open-source contact.
• The contract should pass a bug bounty after the completion of the security audit.
• Public testing.
• Automated anomaly detection systems. - NOT IMPLEMENTED. A simple anomaly detection algorithm is recommended to be implemented to detect behavior that is atypical compared to normal for this contract. For instance, the contract must halt deposits in case a large amount is being withdrawn in a short period of time until the owner or the community of the contract approves further operations.
• Multisig owner account.
• Standard ERC20-related issues. - IMPLEMENTED. It is known that every contract can potentially receive an unintended ERC20-token deposit without the ability to reject it even if the contract is not intended to receive or hold tokens. As a result, it is recommended to implement a function that will allow extracting any arbitrary number of tokens from the contract.
• Crosschain address collisions. ETH, ETC, CLO, etc. It is possible that a transaction can be sent to the address of your contract at another chain (as a result of a user mistake or some software fault). It is recommended that you deploy a "mock contract" that would allow you to withdraw any tokens from that address or prevent any funds deposits. Note that you can reject transactions of native token deposited, but you can not reject the deposits of ERC20 tokens. You can use this source code as a mock contract: extractor contract source code. The address of a new contract deployed using CREATE (0xf0) opcode is assigned following this scheme keccak256(rlp([sender, nonce])). Therefore you need to use the same address that was originally used at the main chain to deploy the mock contract at a transaction with the nonce that matches that on the original chain. Example: If you have deployed your main contract with address 0x010101 at your 2021th transaction then you need to increase your nonce of 0x010101 address to 2020 at the chain where your mock contract will be deployed. Then you can deploy your mock contract with your 2021th transaction, and it will receive the same address as your mainnet contract.

5. Conclusion

The audited smart contract can be deployed. No security issues were found during the audit. Some notes were pointed to optimize gas usage.

It is recommended to adhere to the security practices described in pt. 4 of this report to ensure the contract's operability and prevent any issues that are not directly related to the code of this smart contract.

[seasonaltokens]

Many thanks for your hard work.

Regarding note 3.2, getMiningTarget() and getChallengeNumber() are part of the ERC918 interface and are needed for compatibility with existing mining software: https://eips.ethereum.org/EIPS/eip-918

[yuriy77k]

Many thanks for your hard work.

Regarding note 3.2, getMiningTarget() and getChallengeNumber() are part of the ERC918 interface and are needed for compatibility with existing mining software: https://eips.ethereum.org/EIPS/eip-918

In this case, you may declare challengeNumber and miningTarget as private to avoid duplicate functions.

[seasonaltokens]

Perfect - thanks.

[hsghnr]

Thankyju