This report was prepared to audit the security of the Crypstalstaking contracts developed by the Luxon team. HAECHI AUDIT conducted the audit focusing on whether the system created by the Luxon team is soundly implemented and designed as specified in the published materials, in addition to the safety and security of the Crystalstaking.

In detail, we have focused on the following

The project is an implementation of the ERC-4626 tokenized vault. The user can deposit the asset token and receive the reward-bearing token(xGRND) accordingly. The contract owner can deposit the reward and set the reward period and reward rate. By default, the reward period is set to 8 hours(28800 seconds), which means that every 8 hours the contract emits rewards. The emitted reward is distributed to users pro rata their deposit amount of asset token.

Users who deposit the asset token into the contract can request to withdraw their tokens. The withdrawal request is enqueued to the contract’s mapping. To receive the enqueued asset token, users have to wait until the unstaking period is passed. After the unstaking period, the user can call the collectGrnd function. The function transfers the user’s token and dequeue withdrawal requests from the mapping.

The contract owner has the privilege to set reward rate and period, furthermore, withdraw rewards. The contract can be paused or unpaused by the contract owner and is upgradeable using a proxy pattern.

This report was prepared to audit the security of the xGRND staking contract developed by the Superwalk team. HAECHI AUDIT conducted the audit focusing on whether the system created by the Superwalk team is soundly implemented and designed as specified in the published materials, in addition to the safety and security of the staking contract.

In detail, we have focused on the following

The contracts in scope of audit are implementation of Airdrop and Gacha systems. The project team set the user’s address and token ID, amount before the airdrop(AirdropUser.sol). Based on the information set by the project team, the Gacha Ticket is distributed to the user(AirdropGachaTicket.sol). The Gacha Ticket is an ERC1155 token implementation(GachaTicket.sol) and the user can use this ticket to make use of the Gacha system.

By burning the Gacha ticket, the user can mint a character that has a random ID value. The tier information(GachaData.sol) set by the project team makes the character’s tier in proportion to tier information(GachaMachineByGachaTicket.sol). The character NFT(ERC721) based on the character ID(LCT.sol) is minted to the user.

The project team has the privilege to pause the Gacha process. If the state of the contract is in Inspection, users can not use the Gacha feature(LuxOnService.sol).

This report was prepared to audit the security of the Airdrop and Gacha system-related contracts developed by the Luxon team. HAECHI AUDIT conducted the audit focusing on whether the system created by the Luxon team is soundly implemented and designed as specified in the published materials, in addition to the safety and security of the Airdrop and Gacha implementation.

In detail, we have focused on the following

Sygma is a bridge which can be used to send assets over different blockchains. It can be used to transfer tokens in various standards like ERC20, ERC721, ERC1155. However, Sygma allows much more possibilities with its GenericHandler, which practically allows arbitrary function calls provided that the admin allows such calls with its whitelist and access control system. The system currently works between EVM-based blockchains.

The system works as follows. If a user wants to transfer some ERC20 from chainA to chainB, it first deposits the said ERC20 into the bridge contract of chainA. The contract will then lock the tokens in chainA, then emit an event which implies a deposit was created. The relayers, off-chain operators of the system, will listen to these events and will cooperate with each other to sign and send the appropriate transactions on the destination blockchain, which is chainB in this case.

To sign these transactions, the relayers use a cryptographic method known as Threshold Signatures, or Threshold ECDSA in this case. Using Threshold ECDSA technology, the relayers, which each hold a share of the full ECDSA private key, can sign appropriate transactions without ever knowing the full private key. Also, in the case of an abort, the system can identify the relayer which caused the abort, leading to a more safe system.

The smart contracts handle deposits by users and contract calls by the relayers. The bridge contract will receive these requests by users and relayers, and send them to the appropriate handler contracts. These contracts, which are divided by their usage (for example, the type of token it transfers) will handle the transfers, mints and burns as necessary.

There is also a fee handler, which deals with the fee logic, fee collection, and fee transfers. A fee oracle is used to get the required information to calculate the fees as well.

Our audit covers the Threshold Signature scheme implementation and the smart contracts, but the fee oracle and event listeners of the relayers are not a part of the scope. However, we did find some bugs in the event listeners, which we will share in our audit report below.

This report was prepared to audit the security of the Sygma bridge and related contracts developed by the Sygma team. HAECHI AUDIT conducted the audit focusing on whether the system created by the Sygma team is soundly implemented and designed as specified in the published materials, in addition to the safety and security of the bridge.

In detail, we have focused on the following -