Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to query ContractInfo for a contract #1082

Closed
ethanfrey opened this issue Sep 7, 2021 · 2 comments · Fixed by #1089
Closed

Allow to query ContractInfo for a contract #1082

ethanfrey opened this issue Sep 7, 2021 · 2 comments · Fixed by #1089
Milestone

Comments

@ethanfrey
Copy link
Member

This is based on ideas from CosmWasm/wasmd#584 which have come up in Discord several times from a number of different groups. Basically, people want to:

  1. Check if an address is a contract or an external account
  2. Check what code_id is behind a contract (maybe we only allow unmodified cw20-base for example)
  3. Check on the admin / migratability of a contract

We may also want to allow to see if the contract (actually the linked code_id) is pinned per CosmWasm/wasmd#596

We can model it on the existing grpc client response, particularly the ContractInfo type.

Query:

pub enum WasmQuery {
    Smart { ... },
    Raw { ... },
    ContractInfo {
        contract_addr: String,
    }
}

Response:

pub struct ContractInfoResponse {
   // these seem essential
    pub code_id: u64,
    pub creator: String,
    pub admin: Option<String>,

    // this would be useful info, but maybe not easily available?
    pub pinned: bool,

    // TODO: is this covered by other IBC queries already?
    pub ibc_port: Option<String>,
    
    // also on gRPC return value, but maybe we drop them?
    pub label: String,
    pub created: AbsoluteTxPosition,
    pub extension: Option<Any>,
}

I would love feedback from @alpe and @webmaster128 on the API design here. It is a non-breaking addition to the API, and quite useful functionality. We should just review what data and in what format.

@alpe
Copy link
Contributor

alpe commented Sep 8, 2021

pub pinned: bool,

Is stored in a second index and available

pub ibc_port: Option<String>,

Is in the IBC queries already

pub created: AbsoluteTxPosition,

We are not exposing AbsoluteTxPosition to clients and should not do it here as well, IMHO

pub extension: Option<Any>,

I am not sure if we should support this. The extension would be chain agnostic and has impact on contract portability. It could lead to tight coupling with the persistence object.
Custom queries may a be a cleaner way to get the information (when supported) and contracts won't have to deal with protobuf.

@ethanfrey
Copy link
Member Author

Taking in Alex's feedback, maybe we end up with:

pub struct ContractInfoResponse {
    pub code_id: u64,
    pub creator: String,
    pub admin: Option<String>,
    pub pinned: bool,
    /// block this was created at
    pub created_height: u64,

    pub ibc_port: Option<String>,
}

I looked up the IBC query and it only returns the PortID for the current contract. Not for another contract. Not sure if this would be useful until loopback ibc connections are fully enabled (they exist in theory), but may already be interesting as None/Some(_) info. eg. "a token contract that doesn't want to be passed over IBC and thus disallows transferring tokens to any address with ibc_port set"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants