Connext has made another mistake? Learn about the Connext airdrop claim incident in one article.

Connext's latest mistake? Read about the airdrop claim incident in one article.

Original | Odaily Planet Daily

Author | Qin Xiaofeng

After waiting for two weeks, Layer 2 interoperability protocol Connext finally opened the airdrop application tonight (URL: https://airdrop.connext.network/claim/52), but a major incident occurred.

Just half an hour after the application was opened, the encrypted KOL “Zhu Zhu Bang” posted a message stating that the Connext airdrop contract may have a vulnerability. “Scientists” can use the vulnerability to steal other users’ NEXT airdrops indefinitely, and attached frequent application records starting with 0x44Af (click to jump).

• The roller coaster trend behind Cyber explosive long liquidation, short selling, and a carefully planned hunting game by market makers.
• Revisiting EIP-1559 Is Ethereum safer two years after the proposal has been implemented?
• Asset management giant Fidelity report Where does the value of ETH come from? How to conduct valuation?

This news spread widely in the community, and then some users analyzed the on-chain information and found that the address starting with 0x44Af was only officially created today. After the airdrop was opened, it was claimed more than 230 times. All the tokens obtained were sold and exchanged for ETH, USDT, and USDC, with a profit of about $39,000.

At this time, the Connext airdrop contract also malfunctioned, and some users reported that they could not successfully claim the airdrop. There were rumors in the community that the official had closed the airdrop application due to the vulnerability.

However, the truth is that the Connext airdrop contract does not have a vulnerability.

Encrypted KOL “Zhu Zhu Bang” said that the Connext airdrop contract is secure, and his initial analysis misled readers. He said that although the Connext airdrop contract stipulates that the sender and recipient of the airdrop can be different addresses, the original address needs to be signed and authorized to be called.

“The first claim method is claimBySignature, and the last parameter is the signature information passed. This ‘signature’ is obtained by the user using the smart contract or other methods to call. So we can understand that _signature is a voucher, and the user can get the token of the _beneficiary address by holding this voucher.” He added that the address starting with 0x44Af should be a studio for token collection, not a vulnerability in the contract itself.

The SlowMist security team told Odaily Planet Daily that there is no obvious vulnerability in the Connext airdrop contract, which caused others to claim the airdrop on behalf of others.

Users can claim the NEXT token through the claimBySignature function of the NEXT Distributor contract, which has the roles of recipient and beneficiary: the recipient role is used to receive the claimed NEXT token, and the beneficiary role is the eligible address to claim the NEXT token, which has been determined when the Connext protocol announced the airdrop qualification. When a user claims the NEXT token, the contract will perform two checks: one is to check the signature of the beneficiary role, and the other is to check whether the beneficiary role is eligible to claim the airdrop.

During the first check, it will check whether the recipient passed in by the user is signed by the beneficiary role, so it is impossible to pass the check with a randomly passed recipient address without the beneficiary’s signature. Even if you specify a beneficiary address to construct a signature, you can pass the signature check, but you cannot pass the second check for the eligibility to claim the airdrop. The check for the eligibility to claim the airdrop is performed through Merkel proof, and the proof should be generated by the official Connext protocol. Therefore, users who are not eligible to claim the airdrop cannot bypass the check and claim other people’s airdrops.

In summary of the above analysis, if User A’s address is eligible for claiming, they can authorize User B to make the claim. The reason why the address starting with 0x44Af can claim so many tokens is that multiple qualified addresses controlled by this entity have authorized it, not because of hackers exploiting vulnerabilities.

However, what’s interesting is that before the airdrop was launched, Connext had already taken action against the witch addresses, inviting the community to help the team screen these addresses. They were willing to reward the reporters with 25% of the recovered NEXT tokens. According to official data, a total of 5,725 witch addresses were identified and removed from the eligibility list, resulting in the retrieval of 5,932,065 tokens.

However, from the performance tonight, it seems that the anti-witch action has left behind a large number of fish that slipped through the net, and even added many obstacles to the entire airdrop process.

Arjun Bhuptani, a core contributor of Connext, stated that the address starting with 0x44Af is a witch bot. This bot sent a large number of junk requests to Tokensoft’s backend, causing their API to crash. This may also be the reason why the airdrop claiming interface could not be used. (Note: Preventing others from making claims may be in order to obtain a better selling price.)

The good news is that the official team has already noticed this issue, and the airdrop will be reopened. Connext stated in their announcement, “We are aware of the issue affecting the airdrop website, which prevents users from claiming. We have detected bot activity that has overloaded our partner and service provider Tokensoft’s servers. They are actively working to resolve this issue for a normal claim process. Everything should return to normal soon.”

We will continue to update Blocking; if you have any questions or suggestions, please contact us!