postkillo.blogg.se - february 2022

Polymath software manual upgrade#
Polymath software manual full#
Polymath software manual verification#

The following documentation was available to the audit team:

Polymath software manual full#

Sound Architecture: Evaluation of the architecture of this system through the lens of established smart contract best practices and general software best practices.Ĭode Correctness and Quality: A full review of the contract source code. Security: Identifying security related issues within each contract and within the system of contracts. The audit activities can be grouped in the following three categories: The focus of the audit was to verify that the smart contract system is secure, resilient and working according to its specifications.

Co-auditors: Sergii Kravchenko, Steve Marx.

7 Business Logic Review v2.2.0 to v3.0.0 ModulesĬonsenSys Diligence conducted a security audit on the Polymath Core smart contracts that comprise a system for launching regulatory-compliant securities tokens on a decentralized blockchain.

3.34 LockUpTransferManager._removeLockUpFromUser checks for an impossible condition.

3.33 SecurityToken / STGetter storage layout is hard to maintain.

3.32 EtherDividendCheckpoint and ERC20DividendCheckpoint division by zero.

3.31 public functions in TokenLib could be external instead.

3.30 Modules shouldn't be casted to IBoot.

3.29 Redundant pause and unpause functions in TransferManager.

3.28 Module.takeUsageFee() allows admins to drain a module's approved POLY tokens.

3.26 Use latest stable version of Solidity.

3.25 PolyToken - events are redefined in the implementation.3.24 SecurityToken/STGetter (ERC1643) getAllDocuments - can be cause gas or memory issues if used.3.23 SecurityToken - authentication modifier onlyTokenFactory is never used.3.22 Module - authentication modifier onlyFactoryOwner and onlyFactoryOrOwner are never used.3.20 Improve Code Reusability - Use const variables instead of literals for EIP-1066 status codes.3.19 deleteDelegate should be implemented without array iteration in permission manager.3.18 SecurityToken - Missing Input Validation changeName.3.17 Where possible, a specific contract type should be used rather than address.3.16 SecurityToken - security token name change may cause inconsistency.3.15 Different implementations for the same modifier whenNotPausedOrOwner.3.14 SecurityTokenRegistry does not inherit from ISecurityTokenRegistry.3.13 VestingEscrowWallet - Integer Underflow and unchecked array access in pushAvailableTokensMulti().

Polymath software manual upgrade#

3.12 Security token upgrade info should be editable.

3.11 partitionsOf function always returns empty array.

3.10 _returnPartition function of SecurityToken always returns UNLOCKED partition.

3.9 _balanceOfByPartition function returns wrong value.

3.8 ModuleRegistry - Risks of allowing custom modules in the system.

Polymath software manual verification#

3.7 ModuleRegistry - Custom module verification should be bounded to module version.

3.6 Transfer decisions by default should be consistent.

3.5 ModuleRegistry - Custom modules can block their own removal.

3.4 No new ST can be created after implementation upgrade.

3.3 Polymath can arbitrarily change prices during a USDTieredSTO token sale.3.2 Unpredictable behavior due to front running or general bad timing.3.1 SecurityToken contract should always be initialized.