Skip to content

Incorrect Contract Address Calculation When Using Vec<H160> in Constructor #581

@AlexD10S

Description

@AlexD10S

A hacker of the Blockspace Synergy Hackathon reported this issue when trying to deploy a ink!v6 smart contract using https://ui.use.ink/
After significant debugging, it seems that the problem is from incorrect contract address calculation when the constructor includes a Vec<H160> parameter.

Reproduction Example

Here is a minimal version of the reported contract:

#![cfg_attr(not(feature = "std"), no_std, no_main)]

#[ink::contract]
mod simple_dao {
    use ink::prelude::vec::Vec;
    use ink::H160;


    #[ink(storage)]
    pub struct SimpleDao {
        members: Vec<H160>,
    }

    #[ink(event)]
    pub struct DaoInitiated {
        #[ink(topic)]
        members: Vec<H160>,
    }


    impl SimpleDao {
        /// Initialize the DAO with founding members
        #[ink(constructor)]
        pub fn new(
            members: Vec<H160>,
        ) -> Self {
            assert!(members.len() > 0, "Invalid number of members specified.");

            let mut dao = Self {
                members: members.clone(),
            };

            Self::env().emit_event(DaoInitiated {
                members,
            });

            dao
        }

        /// Get all DAO members
        #[ink(message)]
        pub fn get_members(&self) -> Vec<H160> {
            self.members.clone()
        }
    }
}

Issue Behavior

When deploying this contract with 3 random Ethereum-like addresses using the UI:

Image
  • UI shows deployment at: 0x6E3b7ee114b66a4F0d9bF8bc2e9F8D4C741F2c58
  • Actual contract deployed at: 0x56480b9e6ab13ce453728e193ce1f2826049ffd6 (confirmed via Polkadot JS Apps)

This mismatch causes UI interactions to fail unless the user manually updates the contract address.

Manually replacing the incorrect address in the UI with the correct one allows proper interaction with the contract.

Suggested Fix

Retrieve the contract address directly from the emitted event instead of calculating it manually.
Refactor proposed in cargo-contracts too: use-ink/cargo-contract#2067

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions