The following content is compiled and edited by the cryptocurrency enthusiast Xiaowaiwai and the team, representing only personal recent opinions and not investment advice or judgment on the below projects. Everything is based on actual, genuine materials and the views provided by well-known community leaders and information available during bear and bull markets!
 
On April 25th, according to feedback from several community members, the official website of io.net experienced a malfunction, suspected of being hacked with front-end data tampered with. Users should be aware of the risks themselves.

The io platform is suspected of being hacked, and this incident occurred right before the scheduled snapshot date. It is said that the attack was a retaliation by hackers after io had dealt with 300,000 of their virtual miners. From the DC support channel, many reported seeing numerous devices on the front-end page that didn't belong to them, along with prompts to join a Telegram channel. Moreover, the admins are stubbornly denying it, claiming it's a bug. Do they think users are fools?
 
As users notice the hack, panic is gradually spreading throughout the community. If this hacking incident isn't handled well, even if the project is impressive, there could be significant fluctuations in the cryptocurrency's price.

Regarding this incident, the person in charge also issued a public statement explaining that metadata was not involved, so there is no need for concern. Moving forward, they will enhance protection. This announcement has gradually reassured the users.

The impact of this event is quite significant. If user data is leaked, attackers could gain access to users' personal information, account passwords, transaction records, and other sensitive data. This would constitute a serious violation of users' privacy and could lead to identity theft and financial fraud.
 
How hackers corrupt other users' data:
 
The issue mentioned earlier, the lack of security awareness on the part of io.net, plays a big role here. In the mentioned reporting interface, there's essentially no authentication implemented. You just need to acquire USER_ID and DEVICE_ID to manually report a device, which also explains why it was possible to add so many devices previously – all it takes is one HTTP Call!
Here, by simply providing USER_ID and DEVICE_ID, one can insert a new device into the official system. The question then becomes how to obtain this information.
To get the Device ID, one can see all devices' information in the official Explore section. Through capturing the interface and iterating, it's possible to obtain all DEVICE_IDs.
To get the USER ID, note that this method has already been reported to the official security team and has been fixed a few days ago. The principle is very straightforward. During the earliest Worker initialization process, the device would fetch its own status, such as whether it is terminated or in other states, and stop running. This interface was able to provide User IDs until its recent fix.



So, a few days ago, it was sufficient to obtain everyone’s USER_ID by using the DEVICE_ID; obtaining these two IDs would allow arbitrary reporting of corresponding devices and accessing other people’s networks.
 
We have witnessed the vigorous development of the digital economy, where blockchain has created an economic trust system based on smart contracts, a new species independent of the traditional financial system. The blockchain ecology includes a mining economy, decentralization philosophy, peer-to-peer payment and settlement, consensus mechanisms, and more.
Additionally, in the blockchain ecosystem, the financial valuation, accounting, and related tax and legal issues specific to virtual currencies significantly differ from traditional financial, tax, and legal systems.
Regardless of how the economy and technology develop, everything about a company ultimately reflects in its financial data. Blockchain projects inherently possess financial characteristics and are risky for investors if all information, particularly financial information, is provided solely by the project organizers. Like traditional businesses, blockchain projects should also provide financial audit reports to investors, ensuring that investors receive returns, which constitutes a healthy economic entity. This is the fundamental rationale for the need for independent third-party audits in the blockchain sector.
 
Many project organizers share a common ailment in the crypto project sphere, and the majority of these projects are still in their conceptual early stages, with actual development and implementation proving difficult. Additionally, crypto investors tend to seek quick profits, so the project organizers initially appear financially healthy, but soon encounter a series of issues. The crux of these issues often lies in human nature, which ironically is what blockchain’s decentralized, “cold” code aimed to mitigate by eliminating “evil” human impulses. However, most ICO and IEO projects domestically have encountered problems due to human weaknesses like greed exhibited by project organizers.
Thus, for ordinary investors, there remains no simple method of discerning potential “shave-wool” projects. Ultimately, the most important aspect of any investment is the integrity of the people and teams involved.
 
Currently, in the industry, another hot topic similar to io.net is the dark web-promoted Defi project ORIGIN Aladdin, which we have also studied extensively.



The Polygon network's encrypted universe project Origin has opened its DeFi3.0 ecosystem token LGNS contract. Although I reverse-engineered their contract at the start of the project, I didn't thoroughly analyze their code because it was a remodel from the renowned OlympusDAO.



After the project code was audited by Certik in the past two days, the project team open-sourced the LGNS token contract. Normally, open-sourcing an ERC20 token contract isn't particularly remarkable, but given the persistent private messages from fans requesting an analysis, I'll provide a brief interpretation of their code:
Open your browser and enter the blockchain address for the Polygon chain: polygonscan.com. In the search box, type in the token contract address: 0xeb51d9a39ad5eef215dc0bf39a8821ff804a0f01. You can see that the Contract tab slightly lower down the page now has a check mark (✅) next to it. Click to view the contract details, and at the top of the contract detail pane, there are three buttons: on the left is the code, in the middle is the Read Contract page, and on the right is the Write Contract page.
 
Let's first look at the code. The LGNS code was developed using Solidity and compiled under version 0.7.5. There's a yellow exclamation mark on the right side of the page, indicating that this version of the Solidity compiler has some bugs. I checked it out, and there are indeed a few minor, discreet bugs. Basically, every version of the Solidity compiler has some minor bugs, nothing too serious.
 
Below is the specific code, the contract's ABI, and the deployment QR code. With these, anyone can verify whether the contract matches the source code.
 
Next, let's move on to some key points. We’ll read some important information from this contract. Click the "Read Contract" button at the top of the column, and you'll see a page displaying a list of readable content.
 
Item 1: The constant DEFAULT_ADMIN_ROLE is used to indicate whether a user has administrative privileges.
 
Item 2: DOMAIN_SEPARATOR pertains to the EIP712 standard, and is used during signing to prevent cross-domain attacks.
 
Item 3: Another contract constant, INTERN_SYSTEM, is a permission marker. This value is rarely seen and is used with items 15 and 16; it involves specific addresses:
 
0x5E4E7CaDB7c3d10E3bC96fb830A724448d9B4351, the contract creation address.
0xA304823C775d13fc851379C75e2b6f300E223234, the fee receiving address.
This permission is designed to prevent the need to collect fees on internal contract address transactions and to avoid reentrancy errors.
Item 4: Also a permission indicator constant, used with items 15 and 16 to manage specific addresses,
 
0x7B9B7d4F870A38e92c9a181B00f9b33cc8Ef5321, the Aladdin project’s treasury contract.
0x806FDAb92B0Fc7fBE4bbBE5117A54cAa9283d5a4, an Aladdin project’s reward contract.
Both addresses have minting permissions, likely as part of the project’s economic model design.
Item 5: PERMIT_TYPEHASH is used for EIP2612 signature verification.
 
Item 6: PRECISION, upon review, is used to calculate the fee rate, currently set at 100,000.
 
Item 7: allowance represents the standard ERC20 approval limit, commonly seen as the Approve/authorization quantity.
 
Item 8: balanceOf is also standard ERC20, retrieving the token balance on an address.
 
Item 9: buyFeeRatio, currently set at 0, was initially set at a high value at contract creation and quickly reduced, serving as a precaution against frontrunning attacks from arbitrageurs during project launch. This parameter was later reset to zero after normal project commencement.
 
Item 10: buyFeeReceiver works in conjunction with item 9, receiving the fee at project launch.
 
Item 11: decimals for ERC20 standard. For instance, ETH has 18 decimal places, whereas the LGNS has 9, considered for financial reasons.
 
Item 12: feeRatio, indicative of the transaction fee rate, currently at 5000 or 5% when divided by the value from item 6 (5000/100000).
 
Item 13: The fee receiving address is a smart contract, presumably distributing the 5% fee.
 
Item 14: getRoleAdmin is part of AccessControl, unused in the LGNS contract, typically involved during contract setup using setRoleAdmin to manage permission addresses, omitted possibly to simplify and eventually discard permissions.
 
Item 15: getRoleMember retrieves addresses with specific permissions, working in tandem with item 16 to acquire addresses with particular permissions.
 
Item 16: getRoleMemberCount reads the number of addresses with a certain permission, used with item 15 to access a list of addresses with specific permissions.
 
Item 17: hasRole from AccessControl evaluates whether an address has a certain permission.
 
Item 18: mainpair is the main trading pair for the project, focusing on trading depth and the primary AMM battleground.
 
Item 19: name is the token name, standard data.
 
Item 20: nonces are used in ERC2612.
 
Item 21: symbol is the token’s abbreviation.
 
Item 22: totalSupply is the total issuance, standard for ERC20.
The ADMIN rights of the LGNS contract have been relinquished.
 
At the same time, it’s rare to see a project that completes all the audits from the most authoritative agencies in the circle, including Certik, Armors, and AVE, which was unexpected by the editor. We specifically checked the official websites of several auditing firms and present them to you below:





We can see that whether it's the full-chain execution contract, the treasury contract, or the audits of the token contracts, all have been completed. The equity token LGNS has renounced its permissions, and the contract has also been open-sourced. It can be said to be nearly perfect. The project team has essentially eliminated human malfeasance through technical means. It seems that ORIGIN is indeed a relatively reliable team.