--- title: "QueryConsumerChain returns the consumer chain associated with the provided consumer id" method: GET path: "/interchain_security/ccv/provider/consumer_chain/{consumer_id}" tags: ["Query"] --- # QueryConsumerChain returns the consumer chain associated with the provided consumer id `GET /interchain_security/ccv/provider/consumer_chain/{consumer_id}` ## Request - Base URL: `https://api.mantrachain.io` (the document declares no server; this is the origin it was published from) - URL: `https://api.mantrachain.io/interchain_security/ccv/provider/consumer_chain/{consumer_id}` - Auth: none declared ## Path parameters - `consumer_id` string, required ## Response `200` A successful response. - object - `consumer_id` string - `chain_id` string - `owner_address` string - `phase` string - `metadata` object - `name` string - `description` string - `metadata` string - `init_params` object - `initial_height` object: the proposed initial height of new consumer chain. For a completely new chain, this will be {0,1}. However, it may be different if this is a chain that is converting to a consumer chain. - `revision_number` string, uint64 - `revision_height` string, uint64 - `genesis_hash` string, byte: The hash of the consumer chain genesis state without the consumer CCV module genesis params. It is used for off-chain confirmation of genesis.json validity by validators and other parties. - `binary_hash` string, byte: The hash of the consumer chain binary that should be run by validators on chain initialization. It is used for off-chain confirmation of binary validity by validators and other parties. - `spawn_time` string, date-time: spawn time is the time on the provider chain at which the consumer chain genesis is finalized and all validators will be responsible for starting their consumer chain validator node. - `unbonding_period` string: Unbonding period for the consumer, which should be smaller than that of the provider in general. - `ccv_timeout_period` string - `transfer_timeout_period` string - `consumer_redistribution_fraction` string: The fraction of tokens allocated to the consumer redistribution address during distribution events. The fraction is a string representing a decimal number. For example "0.75" would represent 75%. - `blocks_per_distribution_transmission` string, int64: BlocksPerDistributionTransmission is the number of blocks between ibc-token-transfers from the consumer chain to the provider chain. On sending transmission event, `consumer_redistribution_fraction` of the accumulated tokens are sent to the consumer redistribution address. - `historical_entries` string, int64: The number of historical info entries to persist in store. This param is a part of the cosmos sdk staking module. In the case of a ccv enabled consumer chain, the ccv module acts as the staking module. - `distribution_transmission_channel` string - `connection_id` string: The ID of the connection end on the provider chain on top of which the CCV channel will be established. If connection_id == "", a new client of the consumer chain and a new connection on top of this client are created. Note that a standalone chain can transition to a consumer chain while maintaining existing IBC channels to other chains by providing a valid connection_id. - `power_shaping_params` object - `top_N` integer: Corresponds to the percentage of validators that have to validate the chain under the Top N case. For example, 53 corresponds to a Top 53% chain, meaning that the top 53% provider validators by voting power have to validate the proposed consumer chain. top_N can either be 0 or any value in [50, 100]. A chain can join with top_N == 0 as an Opt In chain, or with top_N ∈ [50, 100] as a Top N chain. - `validators_power_cap` integer: `validators_power_cap` corresponds to the maximum power (percentage-wise) a validator can have on the consumer chain. For instance, if `validators_power_cap` is set to 32, no validator can have more than 32% of the total voting power of the consumer chain. The power cap is intended as a safeguard against a validator having too much power on the consumer chain and hence "taking over" the consumer chain. To respect this power cap, the voting powers of the validators that run the consumer chain are decremented or incremented accordingly. It is important to note that the voting powers of validators on the provider do **not** change. For example, assume that the provider chain has among others, validators `A`, `B`, `C`, and `D` with voting powers 100, 1, 1, 1 respectively. Assume that only those 4 validators opt in on a consumer chain. Without a power cap set, validator `A` would have 100 / (100 + 1 + 1 + 1) = ~97% of the total voting power on the consumer chain, while validators `B`, `C`, and `D` would have 1 /(100 + 1 + 1 + 1) = ~1% of the total voting power on the consumer chain. If `validators_power_cap` is set to 30%, then the voting power of `A` would be reduced from 100 to 30 on the consumer chain, the voting power of `B` would be increased from 1 to 25, and the power of `C` and `D` would be increased from 1 to 24. After those modifications, `A` would have 30 / (30 + 25 + 24 + 24) = ~29% of the total voting power of the consumer chain, `B` would have 25 / (30 + 25 + 24 + 24) = ~25%, and `C` and `D` would both have 24 / (30 + 25 + 24 + 24) = ~23%. Naturally, there are many ways to change the voting powers of validators to respect the power cap, and ICS chooses one of them (see the `NoMoreThanPercentOfTheSum` function). Note that respecting `validators_power_cap` might NOT always be possible. For example, if we have a consumer chain with only 5 validators and `validators_power_cap` is set to 10%, then it is not possible to respect the `validators_power_cap`. If the voting power of each validator is capped to a maximum of 10% of the total consumer chain's voting power, then the total voting power of the consumer chain would add up to 50% which obviously does not make sense (percentages should add up to 100%). In cases where it is not feasible to respect the power cap, all validators on the consumer chain will have equal voting power in order to minimize the power of a single validator. Thus, in the example of 5 validators and a `validators_power_cap` set to 10%, all validators would end up having 20% of the total voting power on the consumer chain. Therefore, `validators_power_cap` operates on a best-effort basis. For more information on the power cap and other power-shaping parameters, please refer to the ICS docs and specifically `interchain-security/docs/docs/features/power-shaping.md`. - `validator_set_cap` integer: Corresponds to the maximum number of validators that can validate a consumer chain. Only applicable to Opt In chains. Setting `validator_set_cap` on a Top N chain is a no-op. - `allowlist` string[] - `denylist` string[] - `min_stake` string, uint64: Corresponds to the minimal amount of (provider chain) stake required to validate on the consumer chain. - `allow_inactive_vals` boolean: Corresponds to whether inactive validators are allowed to validate the consumer chain. - `prioritylist` string[]: Corresponds to a list of provider consensus addresses of validators that should have PRIORITY to validate on the consumer chain, meaning as long as they are eligible/opted in to validate on the consumer chain, the validator set will be filled with these validators first, and other validators will be added to the validator set only if there are not enough eligible priority validators. - `infraction_parameters` object - `double_sign` object - `slash_fraction` string, byte - `jail_duration` string - `tombstone` boolean - `downtime` object - `slash_fraction` string, byte - `jail_duration` string - `tombstone` boolean - `client_id` string ## Other responses - `default`: An unexpected error response. --- [API](https://skmtc.dev/mantrachain/apis/mantra-grpc-gateway-docs.md) - [All operations](https://skmtc.dev/mantrachain/apis/mantra-grpc-gateway-docs/llms.txt) - [OpenAPI document](https://skmtc.dev/mantrachain/apis/mantra-grpc-gateway-docs/revisions/641ce457f7fd?raw)