A-Z smart contract audit process by Ambisafe

1. Source​ ​Code​ ​Review
Prepared​ ​for​ ​Talla•​ ​December​ ​​ ​2017
V1.0
1.​ ​Table​ ​of​ ​Contents
1.​ ​Table​ ​of​ ​Contents
2.​ ​Executive​ ​Summary
3.​ ​Introduction
4.​ ​Findings
4.1.​ ​Problems​ ​in​ ​the​ ​ERC-20​ ​specification
4.2.​ ​Race​ ​condition​ ​after​ ​AssetWithWhitelist​ ​contract​ ​creation
4.3.​ ​No​ ​public​ ​visibility​ ​modifiers​ ​for​ ​public​ ​methods
4.4.​ ​Use​ ​of​ ​Solidity​ ​versions​ ​prior​ ​0.4.18
4.5.​ ​Opt-out​ ​upgrade
5.Closing​ ​Remarks
DRAFT

2. 2.​ ​Executive​ ​Summary
In December 2017, Talla engaged ​Coinspect to perform a security audit of the Ambisafe token
contracts.​ ​The​ ​contract​ ​was​ ​received​ ​in​ ​the​ ​following​ ​archive:
https://drive.google.com/drive/u/1/folders/10ALrQ7biCIjahFOJnnTi7_yjb4GrqkIw
The objective of the audit was to evaluate the security of the smart contracts. During the
assessment,​ ​Coinspect​ ​identified​ ​the​ ​following​ ​issues:
High-Risk Medium​ ​Risk Low​ ​Risk Zero​ ​Risk
0 0 5 0
Only​ ​5​ ​low​ ​risk​ ​issues​ ​were​ ​found,​ ​and​ ​the​ ​overall​ ​quality​ ​of​ ​the​ ​audited​ ​code​ ​was​ ​good.
3.​ ​Introduction
The​ ​Ambisafe​ ​contracts​ ​comprises​ ​the​ ​following​ ​contracts​ ​working​ ​together:
● Ambi.sol
● Ambi2.sol
● Ambi2Enabled.sol
● Ambi2EnabledFull.sol
● AmbiEnabled.sol
● AssetWithAmbi.sol
● RegistryICAP.sol
● MultiAssetEmitter.sol
● ERC20Interface.sol
● AssetWithWhitelist.sol
● Safe.sol
● StackDepthLib.sol
● EToken2Interface.sol
● EToken2.sol
● EToken2Emitter.sol
● EventsHistory.sol
● helpersBytes32.sol
● helpersReturnData.so
● Asset.sol
● AssetInterface.sol
● AssetProxy.sol
● AssetProxyInterface.sol
©​ ​2017​ ​Coinspect DRAFT/1

3. The​ ​AssetProxy​ ​is​ ​an​ ​ERC-20​ ​compliant​ ​token​ ​smart​ ​contrac,​ ​that​ ​forwards​ ​all​ ​calls​ ​to​ ​an
associated​ ​Asset​ ​smart​ ​contract​ ​that​ ​provides​ ​an​ ​upgradeable​ ​back-end.​ ​All​ ​requests​ ​end​ ​up
being​ ​managed​ ​by​ ​the​ ​EToken2​ ​contract.​ ​This​ ​contract​ ​manages​ ​multiple​ ​assets.​ ​Also​ ​EToken2
allows​ ​the​ ​recovery​ ​of​ ​the​ ​funds​ ​in​ ​case​ ​of​ ​a​ ​lost​ ​private​ ​key​ ​by​ ​two​ ​methods:​ ​delegation​ ​of​ ​trust
and​ ​co-signers,​ ​The​ ​source​ ​code​ ​for​ ​the​ ​co-signer​ ​was​ ​not​ ​present​ ​in​ ​the​ ​source​ ​code​ ​package.
The​ ​RegistryICAP​ ​smart​ ​contract​ ​manages​ ​transfers​ ​of​ ​tokens​ ​to​ ​institutions​ ​identified​ ​by​ ​an
ICAP​ ​address.​ ​The​ ​remaining​ ​contracts​ ​manage​ ​access​ ​control,​ ​logging​ ​of​ ​events​ ​and
whitelisting.
A​ ​white​box​ ​security​ ​audit​ ​was​ ​conducted​ ​on​ ​these​ ​smart​ ​contracts.
The present report was completed on December 18th, 2017, by Coinspect. The report includes
all​ ​issues​ ​identified​ ​in​ ​the​ ​audit.
The​ ​following​ ​checks,​ ​related​ ​to​ ​best​ ​practices,​ ​​ ​were​ ​performed:
- Confusion​ ​of​ ​the​ ​different​ ​method​ ​calling​ ​possibilities:​ ​send(),​ ​transfer(),​ ​and​ ​call.value()
- Missing​ ​error​ ​handling​ ​of​ ​external​ ​calls
- Erroneous​ ​control​ ​flow​ ​assumptions​ ​after​ ​external​ ​calls
- The​ ​use​ ​of​ ​push​ ​over​ ​pull​ ​for​ ​external​ ​calls
- Lack​ ​of​ ​enforcement​ ​of​ ​invariants​ ​with​ ​assert()​ ​and​ ​require()
- Rounding​ ​errors​ ​in​ ​integer​ ​division
- Fallback​ ​functions​ ​with​ ​higher​ ​gas​ ​limit​ ​than​ ​2300
- Functions​ ​and​ ​state​ ​variables​ ​without​ ​explicitly​ ​visibility
- Missing​ ​pragmas​ ​to​ ​for​ ​compiler​ ​version
- Race​ ​conditions,​ ​such​ ​as​ ​contract​ ​Reentrancy
- Transaction​ ​front​ ​running
- Timestamp​ ​dependence
- Integer​ ​overflow​ ​and​ ​underflow
- Code blocks that consumes a non-constant amount of gas, that grows over block gas
limit.
- Denial​ ​of​ ​Service​ ​attacks
- Suspicious​ ​code​ ​or​ ​underhanded​ ​code.
- Error​ ​prone​ ​code​ ​constructs
- Race​ ​conditions
©​ ​2017​ ​Coinspect DRAFT/2

4. 4.​ ​Findings
The​ ​list​ ​of​ ​issues​ ​found​ ​follows.
4.1.​ ​Problems​ ​in​ ​the​ ​ERC-20​ ​specification
Low​ ​Risk
Increasing​ ​an​ ​allowance​ ​with​ ​approve()​ ​presents​ ​a​ ​race​ ​condition​ ​because​ ​of​ ​the​ ​non-atomic
implementation​ ​of​ ​the​ ​read​ ​and​ ​write​ ​operations​ ​[1].​ ​If​ ​the​ ​allowed​ ​tokens​ ​are​ ​consumed​ ​just
before​ ​the​ ​new​ ​allowance​ ​is​ ​confirmed,​ ​then​ ​the​ ​sender​ ​may​ ​end​ ​up​ ​allowing​ ​more​ ​than​ ​the
double​ ​of​ ​the​ ​expected​ ​allowance​ ​of​ ​tokens.
Recommendation
Add​ ​the​ ​methods​ ​increaseApproval()​ ​and​ ​decreaseApproval()​ ​to​ ​the​ ​ProxyAsset​ ​contract,​ ​using
as​ ​a​ ​template​ ​the​ ​implementations​ ​in​ ​the​ ​OpenZeppelin​ ​library​ ​[2].
[1]​ ​​https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
[2]​ ​​https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/token/StandardToken.sol#L70
4.2.​ ​Race​ ​condition​ ​after​ ​AssetWithWhitelist​ ​contract​ ​creation
Low​ ​Risk
When​ ​an​ ​AssetWithWhitelist​ ​is​ ​created,​ ​it​ ​has​ ​no​ ​“admin”​ ​role,​ ​no​ ​whitelisted​ ​addresses,​ ​and​ ​not
transfer​ ​restriction​ ​because​ ​restrictionExpiraton​ ​is​ ​set​ ​to​ ​zero.
Therefore​ ​there​ ​is​ ​always​ ​a​ ​window​ ​of​ ​time​ ​after​ ​creation​ ​when​ ​tokens​ ​can​ ​be​ ​transferred
without​ ​whitelisting.
Recommendation
It​ ​is​ ​recommended​ ​that​ ​restrictionExpiraton​ ​is​ ​set​ ​to​ ​0xff...ff​ ​upon​ ​contract​ ​creation​ ​to​ ​prevent
unexpected​ ​transfers.​ ​Also​ ​it’s​ ​important​ ​that​ ​a​ ​contract​ ​creation​ ​checklist​ ​includes​ ​the​ ​setup​ ​of
the​ ​“admin”​ ​role​ ​and​ ​the​ ​setup​ ​of​ ​the​ ​final​ ​restrictionExpiraton​ ​value.
4.3.​ ​No​ ​public​ ​visibility​ ​modifiers​ ​for​ ​public​ ​methods
Low​ ​Risk
Solidity methods are public by default. However it’s a good programming practice to inform this
to the reader by adding the “public” visibility modifier to function definitions to prevent
confusions.
©​ ​2017​ ​Coinspect DRAFT/3

5. Recommendation
Add​ ​the​ ​“public”​ ​​ ​visibility​ ​modifiers​ ​to​ ​public​ ​methods.
4.4.​ ​Use​ ​of​ ​Solidity​ ​versions​ ​prior​ ​0.4.18
Low​ ​Risk
Solidity has fixed several vulnerabilities between release 0.4.8 an the release 0.4.18 [3]. The
Ambisafe contracts were compiler with version 0.4.8 or 0.4.15, therefore they may be affected
by these vulnerabilities. We analyzed each of the documented vulnerabilities and we believe the
contracts are not affected. However, a small risk that other undocumented vulnerabilities are
present​ ​in​ ​old​ ​releases​ ​of​ ​the​ ​compiler.
[3]​ ​​http://solidity.readthedocs.io/en/develop/bugs.html
Recommendation
If possible, re-deploy the Ambisafe contracts, recompiled with the last Solidity release. If not
possible,​ ​execute​ ​test​ ​cases​ ​for​ ​each​ ​possible​ ​code​ ​path.
4.5.​ ​Opt-out​ ​upgrade
Low​ ​Risk
The​ ​owner​ ​of​ ​an​ ​Asset​ ​can​ ​propose​ ​an​ ​upgrade,​ ​completely​ ​changing​ ​the​ ​back-end​ ​logic​ ​of​ ​an
asset.​ ​Upgrading​ ​is​ ​opt-out,​ ​meaning​ ​that​ ​the​ ​asset​ ​is​ ​upgraded​ ​by​ ​default​ ​if​ ​users​ ​do​ ​not
out-out.​ ​Proposing​ ​an​ ​upgrade​ ​generates​ ​an​ ​event​ ​(UpgradeProposal),​ ​but​ ​it's​ ​not​ ​clear​ ​how
token​ ​holders​ ​will​ ​be​ ​notified​ ​of​ ​the​ ​proposal​ ​on​ ​time.​ ​The​ ​window​ ​for​ ​commitment​ ​of​ ​the
upgrade​ ​is​ ​only​ ​3​ ​days,​ ​so​ ​an​ ​upgrade​ ​could​ ​go​ ​undetected​ ​by​ ​the​ ​community.
Recommendation
Document​ ​in​ ​the​ ​Talla​ ​whitepaper​ ​the​ ​fact​ ​that​ ​the​ ​token​ ​has​ ​an​ ​upgrade​ ​system​ ​so​ ​users​ ​are
aware​ ​they​ ​may​ ​need​ ​to​ ​decide​ ​to​ ​opt-out.​ ​Upgradeability​ ​should​ ​be​ ​a​ ​property​ ​that​ ​can​ ​be
turned​ ​off​ ​forever​ ​by​ ​the​ ​owner​ ​of​ ​an​ ​Asset,​ ​if​ ​there​ ​is​ ​no​ ​plan​ ​to​ ​use​ ​it.
5.Closing​ ​Remarks
It has been a pleasure to work with Talla. We believe that the Ambisafe contracts are free from
critical defects. The scope of the present security audit is limited to smart contract code. It does
©​ ​2017​ ​Coinspect DRAFT/4

6. not cover the technologies and designs related to these smart contracts, nor the frameworks
and wallets that communicate with the contracts, nor the operational security of the company
that created and will deploy the audited contracts. This document should not be read as
investment​ ​or​ ​legal​ ​advice.
©​ ​2017​ ​Coinspect DRAFT/5