近日，北京链安接到部分项目方反映，他们发布ERC20代币后，还没进一步向其它地址分发，就发现一些来源不明的代币在链上转账，即这些代币原始来源并非其合约创建时分配给官方地址的Token。同时，项目方也发现这些Token并非同名创建的其它合约产生的同名币或“假币”，更像是一种并非由其发起的“增发”。
例如，一项目方便反映，他们观察到以太坊链上其代币HJL交易出现异常增发的情况，一些Token似乎在以太坊网络上凭空产生，没有生成记录，说好的区块链“不可篡改可追溯”呢？
这是增发造成的吗？从真正意义上的增发来说，我们认为应该是相关项目发起方或授权方主动发起了一种增加Token供应量的行为，正常情况下，代币的增发有以下几个条件：
这种情况下，我们应该在链上看到增发的记录，比如ERC20 USDT的增发就会有类似这样的记录：
但是，据举报问题的项目方反映，它们并未向0xfa6dd2b9976d67852cc4b3180f1ef8692c4ad87c转账，这个地址似乎有Token“从天而降”。
可以看到，上图记录中，合约创建后产生了4300万枚HJL，转账到0xfee0c开头地址，接着该地址转入0x2ebecf开头地址，接着我们看到了0xfa6dd2开头地址的转账，显然这个地址此前并未获得官方创建的相关Token。
终于，我们发现了玄机所在，智能合约在部署到链上时，在正常发布参数_totalSupply设置供应量的Token的同时，还向地址0xfA6DD2B9976d67852Cc4b3180f1Ef8692c4aD87c 的账户上充值了总供应量 1% 的代币，并且这 1% 的代币并未计入总供应量中，就HJL而言，相当于实际发行了43000000+430000001% = 43000000+430000=43430000 HJL，而多出来的这些HJL似乎被这个地址给“偷”走了。
从地址0xfa6dd2b9976d67852cc4b3180f1ef8692c4ad87c关于HJL的转账来看，它确实给人一种凭空获得HJL的感觉，并转出了330000HJL。
该地址内还剩下10万枚HJL，和转出的HJL加起来总额为43万HJL，符合合约中的操作。
我们进一步参看了该地址的转账记录，发现有不止一个此类“天降横财”式Token，都是未见转入和合约调用，该地址直接向外转出这些Token
这些项目的合约是不是也遇到类似问题呢？我们查询了Phantom Matter (PHTM2)的合约：https://cn.etherscan.com/address/0xbcc4bcc7577e4042d45ae189ba6c0b264d7bab34#code
不出意外的，我们看到了同样的代码，同样的地址，同样的百分之一增发式“偷取”策略，由此可见这实际上是相关合约留有后门，但是项目方表示并不知情，那么他们又是如何中招的呢。
与项目方的沟通进一步了解到，其发币合约并非自己开发，而是在一个名为“易代币”的发币平台完成，接下来的问题就是在使用这个平台的过程中：
平台的模板是否带有这样的代码。如果带有这样的代码，是否这本是其功能设置的一部分，或者是客户支付费用的既定方式。如果有这样的功能和设置，是否明示给客户。于是，我们在测试网上进行了测试，在网站上，用户首先选择发币类型。
接着输入名称、符号、供应量等信息。
最后是支付相应的创建交易费用，然后确认就可以了，全程没有任何地方提及会有最终合约代码中产生的多发1%代币并转到其指定地址的行为，显然这并不是一个其既有的面向客户的功能或者设置。
北京链安已经在测试网络使用了该代币生成网站并部署合约，从合约代码来看，也看到了同样的多发Token并窃取的行为，接收地址也是0xfa6dd2b9976d67852cc4b3180f1ef8692c4ad87c。由此可见，该网站以代币发布平台为名，在为客户提供代币发布服务的同时，在客户不知情的情况下获得代币，一旦相关代币可以交易流通，他们将可以将其卖出获益。
就0xfa6dd2b9976d67852cc4b3180f1ef8692c4ad87c地址关联的项目而言，主要有：
HJL (HJL)
Moneyhome (MH)
Phantom Matter (PHTM2)
CRS (CRS)
Libra Pi (LP)
SMART (SMART)
UCC (UC)
其中部分Token已经在交易所交易，我们也看到了涉事地址向相关交易所转账的记录，可见其模式便是暗中多发1%的Token，待其中有币上所便跟进卖出获利。
整个过程，我们发现项目方处于一种极不安全的“裸奔”状态，在使用所谓的发币平台的时候，整个过程对它们是黑盒的，它们看到的只是些设置选项，根本不知道中间的猫腻。与此同时，尽管代码部署并开验证后会开源，但是使用这样的平台的项目方通常技术能力有限，不会去检查其中的缺陷，而目前很多中小交易所上币的时候也不会对项目方做代码审计要求，这就造成这一代码里如此“张扬”的后门通过层层关卡而未被及时堵截。
在这里，北京链安提醒业内各方，对于涉及智能合约的开发请遵循相应的安全原则，如涉及外包开发请在对其能力评估的同时注意道德风险的评估。最后，智能合约的安全审计环节必不可少，请及时联系专业的安全机构进行相应的安全检测。
（1、 内容来自链得得内容开放平台“得得号”，稿件内容仅代表作者观点，不代表链得得官方立场。2、 凡“得得号”文章，原创性和内容的真实性由投稿人保证，如果稿件因抄袭、作假等行为导致的法律后果，由投稿人本人负责。3、 得得号平台发布文章，如有侵权、违规及其他不当言论内容，请广大读者监督，一经证实，平台会立即下线。如遇文章内容问题，请发送至邮箱：chengyiniu@chaindd.com）
