Skip links
Alex Go Logo

AlexGo Audit Launchpad, Yield Vault and Collateral Rebalancing Pool


CoinFabrik was asked to audit the contracts for the AlexGo project. First we will
provide a summary of our discoveries and then we will show the details of our


The contracts audited are from the git
repository. The audit is based on the commit

The audited contracts are:

clarity/contracts/pool/alex-launchpad-v1-1.clar: Launchpad
contract for IDO creation.
Contract for collateral-token pool creation.
clarity/contracts/pool/yield-vault-alex.clar: Vault for yield

The scope of the audit is limited to those files. No other files in this repository were
audited. Its dependencies are assumed to work according to their documentation.
Also, no tests were reviewed for this audit.


Without being limited to them, the audit process included the following analyses:

● Arithmetic errors
● Race conditions
● Misuse of block timestamps
● Denial of service attacks
● Excessive gas usage
● Needlessly complex code and contract interactions
● Poor or nonexistent error handling
● Insufficient validation of the input parameters
● Centralization and upgradeability
● Weak authentication

Summary of Findings

We found a medium issue and a minor issue. Also, two enhancements were
The two issues were acknowledged.

Security Issues

Privileged Roles

These are the privileged roles that we identified on each of the audited contracts.



The owner is the only role which can create ticket pools, required to start an IDO. It
is also capable of providing tickets to a pool, calling the claiming and refunding
function without waiting for the grace period to end, and transferring the entire
balance of a specific token to the owner.

Approved Operator

This role can also provide tickets to a pool and call the claiming and refunding
functions without waiting for the grace period to end.

IDO Owner

The IDO owners can add tickets to their pool and call the claiming and refunding
functions without waiting for the grace period to end.

Security Issues Found

Severity Classification

Security risks are classified as follows:

● Critical: These are issues that we manage to exploit. They compromise the
system seriously. They must be fixed immediately.
● Medium: These are potentially exploitable issues. Even though we did not
manage to exploit them or their impact is not clear, they might represent a
security risk in the near future. We suggest fixing them as soon as possible.
● Minor: These issues represent problems that are relatively small or difficult
to take advantage of but can be exploited in combination with other issues.
These kinds of issues do not block deployments in production environments.
They should be taken into account and be fixed when possible.

Issues Status

An issue detected by this audit can have four distinct statuses:

● Unresolved: The issue has not been resolved.
● Acknowledged: The issue remains in the code but is a result of an intentional
● Resolved: Adjusted program implementation to eliminate the risk.
● Partially resolved: Adjusted program implementation to eliminate part of the
risk. The other part remains in the code but is a result of an intentional
● Mitigated: Implemented actions to minimize the impact or likelihood of the

Critical Severity Issues

No issues found.

Medium Severity Issues

ME-01 Launchpad: Full Distribution not Guaranteed


● clarity/contracts/pool/alex-launchpad-v1-1.clar:258-287

Launchpad randomness relies on moving positions along a chain of tickets, where
the distance of each step is determined by a random number generator, and for
each position where it stops, that ticket is determined as a winner. Each random
number is the result of a greater number modulus a predefined max_step. This
predefined value is general for each IDO and its formula (simplified for this
explanation) is:

Where registered is the number of tickets registered in the IDO by the players,
and winners is the amount of winner tickets the distribution can have.

As a consequence, full distribution is only guaranteed when

formula register number

because max_step results in one or less than one, and therefore every player wins.

On the other hand, if that relation is not satisfied, fewer tickets might be distributed.
As a clear example, if there were only one winner ticket available and only one
ticket registered, max_step would be equal to 1.5. The player would win if the
position after the step falls between 0 and 1. Therefore, this player has a probability
of winning of just 66.67% in a single-player IDO.


If there are remaining tickets, a new round needs to be initiated, with the max_step
value adjusted to this amount.


Acknowledged. The recommendation will be incorporated into the following IDOs.

Minor Severity Issues

MI-01 Launchpad: Tokens Locked due to Incomplete Distribution


● clarity/contracts/pool/alex-launchpad-v1-1.clar:258-287

If the tokens are not distributed because of the issue described in ME-01, they will
be locked in the contract unless the contract owner calls
transfer-all-to-owner(), which will transfer the tokens back to the owner.


If ME-01 remains unresolved, the IDO owner should be able to extract those tokens.


Acknowledged. The development team considered the conditions of this issue
unlikely to be satisfied.


These items do not represent a security risk. They are best practices that we
suggest implementing.



EN-01 Launchpad: Unnecessary Assertions


● clarity/contracts/pool/alex-launchpad-v1-1.clar:269,353

A block’s VRF seed can be taken from a block already mined, a past block. The seed
used for the IDOs is from the block after the registration ends. However, the
assertions in lines 269 and 353 checks 𝑏𝑙𝑜𝑐𝑘𝐻𝑒𝑖𝑔ℎ𝑡 ≥ 𝑟𝑒𝑔𝑖𝑠𝑡𝑟𝑎𝑡𝑖𝑜𝑛𝐸𝑛𝑑𝐻𝑒𝑖𝑔ℎ𝑡,
while it can also fail because the seed cannot be taken if current block height is at
registration end or the block after it.

Moreover, the assertion in claim-process() will never fail because
get-last-claim-walk-position() is called before, and it will revert if the seed is
not available.


Not implemented. The corresponding fixes are planned to be implemented in the
following iterations.

EN-02 Yield Vault: Misleading Response


● clarity/contracts/pool/yield-vault-alex.clar:161

If activated is equal to false, the response will be (ok true), even when only the
rewards are claimed, and they are not staked.


Not implemented. The corresponding fixes are planned to be implemented in the
following iterations.

Other Considerations

The considerations stated in this section are not right or wrong. We do not suggest
any action to fix them. But we consider that they may be of interest for other
stakeholders of the project, including users of the audited contracts, owners or
project investors.


Launchpad’s claiming and refunding functions are public and do not have
restrictions to be called by the users, when a grace period is passed. However, the
claiming functions require a list of winners ordered in sequence as an input. As a
consequence, if the off-chain task cannot be run, users will need to figure out the
sequence and pay the cost of, at least, the claiming of every user before them.
The refunding functions need the claiming function to be called before because
refund is only available when it is confirmed on-chain that the ticket is not a winner
Moreover, launchpad contract owner can transfer all the tokens in the contract’s


● 2022-04-08 – Initial report based on commit
● 2022-04-19 – Final report based on feedback provided by the development

Disclaimer: This audit report is not a security warranty, investment advice, or an
approval of the AlexGo project since CoinFabrik has not reviewed its platform.
Moreover, it does not provide a smart contract code faultlessness guarantee.