Astroport.fi Astral Assembly - Astroport.fi

The assembly contract uses different block heights when casting a vote and when calculating the total voting power available for a proposal. This situation could allow proposals to bypass the quorum required for approval.

The proposal_quorum is defined as the ratio of total votes to total voting power. However, the calculation of each vote cast and thus total_votes queries XAstro token in proposal.start_block but total_voting_power does so in proposal.start_block - 1, effectively retrieving different states of the XAstro supply. On the other hand, the VxAstro token consistently uses proposal.start_time - 1 in both cases.

To illustrate this issue, take the following example attack scenario which, for simplicity, only considers the XAstro token:

1. Suppose at block height 100 the XAstro's total supply is 1000, proposal_required_quorum set to 10% and proposal_required_threshold set to 20%.

2. In the next block (101), more XAstro tokens are minted, taking the total supply to 1500. At this point, a proposal is submitted.

3. By the end of the voting period, the active proposal will have received 100 votes, 21 of which will be "for" votes.

4. Finally, end_proposal is called on the aforementioned proposal. proposal_quorum will be 100 / 1000 since proposal.start_block - 1 is requested for the denominator instead of 100 / 1500.

This will unfairly mark the proposal as "Passed", since the quorum check requires a smaller than effective total_voting_power to cast votes.

Code Location

contracts/assembly/src/contract.rs

pub fn calc_voting_power(
    deps: &DepsMut,
    sender: String,
    proposal: &Proposal,
) -> StdResult<Uint128> {
    let config = CONFIG.load(deps.storage)?;

    let xastro_amount: BalanceResponse = deps.querier.query_wasm_smart(
        config.xastro_token_addr,
        &XAstroTokenQueryMsg::BalanceAt {
            address: sender.clone(),
            block: proposal.start_block,
        },

contracts/assembly/src/contract.rs

pub fn calc_total_voting_power_at(deps: &DepsMut, proposal: &Proposal) -> StdResult<Uint128> {
    let config = CONFIG.load(deps.storage)?;

    // Total xASTRO supply at a specified block
    let mut total: Uint128 = deps.querier.query_wasm_smart(
        config.xastro_token_addr,
        &XAstroTokenQueryMsg::TotalSupplyAt {
            block: proposal.start_block - 1,
        },
    )?;

NOT APPLICABLE: The underlying logic in storing SnapshotMap effectively reflected the user's voting power (calculated at calc_voting_power) in proposal.start_block - 1. Causing the block height to be selected consistently in all the relevant places.

Timelocks are defined in the assembly contract to allow users of the protocol to react in time if a change made is bad faith or is not in the best interest of the protocol and its users.

The instantiate and update_config functions of the assembly contract do not restrict timelocks (execution_delay_period and proposal_expiration_period) from being greater than or equal to a minimum threshold. Therefore, malicious changes proposed through voting could even be executed immediately if execution_delay_period is not set appropriately.

Code Location

contracts/assembly/src/contract.rs

let config = Config {
    xastro_token_addr: addr_validate_to_lower(deps.api, &msg.xastro_token_addr)?,
    vxastro_token_addr: addr_validate_to_lower(deps.api, &msg.vxastro_token_addr)?,
    builder_unlock_addr: addr_validate_to_lower(deps.api, &msg.builder_unlock_addr)?,
    proposal_voting_period: msg.proposal_voting_period,
    proposal_effective_delay: msg.proposal_effective_delay,
    proposal_expiration_period: msg.proposal_expiration_period,
    proposal_required_deposit: msg.proposal_required_deposit,
    proposal_required_quorum: Decimal::from_str(&msg.proposal_required_quorum)?,
    proposal_required_threshold: Decimal::from_str(&msg.proposal_required_threshold)?,
};

contracts/assembly/src/contract.rs

if let Some(proposal_effective_delay) = updated_config.proposal_effective_delay {
    config.proposal_effective_delay = proposal_effective_delay;
}

if let Some(proposal_expiration_period) = updated_config.proposal_expiration_period {
    config.proposal_expiration_period = proposal_expiration_period;
}

SOLVED: The issue was fixed in commit 6dcfefe59514a85495a4e34a2ec50ea41f0d10d2.

In computer programming, an overflow occurs when an arithmetic operation attempts to create a numeric value that is outside the range that can be represented by a given number of bits – either greater than the maximum value or less than the minimum representable value.

This issue has been raised as informational only, since it was not possible to define a clear exploitation scenario for the affected case.

Code Location

Affected resources

contracts/assembly/src/contract.rs:715:            .checked_add(locked_amount.params.amount - locked_amount.status.astro_withdrawn)?;

SOLVED: The issue was fixed in commit 6dcfefe59514a85495a4e34a2ec50ea41f0d10d2.