swagger: '2.0' info: title: Babylon - gRPC Gateway docs description: A REST interface for state queries version: 1.0.0 paths: /babylon/btccheckpoint/v1: get: summary: BtcCheckpointsInfo returns checkpoint info for a range of epochs operationId: BtcCheckpointsInfo responses: '200': description: A successful response. schema: type: object properties: info_list: type: array items: type: object properties: epoch_number: type: string format: uint64 title: epoch number of this checkpoint best_submission_btc_block_height: type: string format: uint64 title: btc height of the best submission of the epoch best_submission_btc_block_hash: type: string format: byte title: >- hash of the btc block which determines checkpoint btc block height i.e. youngest block of best submission best_submission_transactions: type: array items: type: object properties: key: description: >- key is the position (txIdx, blockHash) of this tx on BTC blockchain Although it is already a part of SubmissionKey, we store it here again to make TransactionInfo self-contained. For example, storing the key allows TransactionInfo to not relay on the fact that TransactionInfo will be ordered in the same order as TransactionKeys in SubmissionKey. type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block transaction: type: string format: byte title: transaction is the full transaction in bytes proof: type: string format: byte title: >- proof is the Merkle proof that this tx is included in the position in `key` TODO: maybe it could use here better format as we already processed and valideated the proof? title: >- TransactionInfo is the info of a tx that contains Babylon checkpoint, including - the position of the tx on BTC blockchain - the full tx content - the Merkle proof that this tx is on the above position title: the BTC checkpoint transactions of the best submission best_submission_vigilante_address_list: type: array items: type: object properties: submitter: type: string format: byte description: >- TODO: this could probably be better typed submitter is the address of the checkpoint submitter to BTC, extracted from the checkpoint itself. reporter: type: string format: byte title: >- reporter is the address of the reporter who reported the submissions, calculated from submission message MsgInsertBTCSpvProof itself title: >- CheckpointAddresses contains the addresses of the submitter and reporter of a given checkpoint title: list of vigilantes' addresses of the best submission title: >- BTCCheckpointInfo contains all data about best submission of checkpoint for given epoch. Best submission is the submission which is deeper in btc ledger pagination: title: pagination defines the pagination in the response type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: >- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: |- QueryBtcCheckpointsInfoResponse is response type for the Query/BtcCheckpointsInfo RPC method default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: pagination.key description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. in: query required: false type: string format: byte - name: pagination.offset description: >- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. in: query required: false type: string format: uint64 - name: pagination.limit description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. in: query required: false type: string format: uint64 - name: pagination.count_total description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. in: query required: false type: boolean - name: pagination.reverse description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 in: query required: false type: boolean tags: - Query /babylon/btccheckpoint/v1/params: get: summary: Parameters queries the parameters of the module. operationId: BtcCheckpointParams responses: '200': description: A successful response. schema: type: object properties: params: description: params holds all the parameters of this module. type: object properties: btc_confirmation_depth: type: string format: uint64 title: >- btc_confirmation_depth is the confirmation depth in BTC. A block is considered irreversible only when it is at least k-deep in BTC (k in research paper) checkpoint_finalization_timeout: type: string format: uint64 title: >- checkpoint_finalization_timeout is the maximum time window (measured in BTC blocks) between a checkpoint - being submitted to BTC, and - being reported back to BBN If a checkpoint has not been reported back within w BTC blocks, then BBN has dishonest majority and is stalling checkpoints (w in research paper) checkpoint_tag: type: string title: >- 4byte tag in hex format, required to be present in the OP_RETURN transaction related to babylon description: >- QueryParamsResponse is response type for the Query/Params RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte tags: - Query /babylon/btccheckpoint/v1/{epoch_num}: get: summary: BtcCheckpointInfo returns checkpoint info for a given epoch operationId: BtcCheckpointInfo responses: '200': description: A successful response. schema: type: object properties: info: type: object properties: epoch_number: type: string format: uint64 title: epoch number of this checkpoint best_submission_btc_block_height: type: string format: uint64 title: btc height of the best submission of the epoch best_submission_btc_block_hash: type: string format: byte title: >- hash of the btc block which determines checkpoint btc block height i.e. youngest block of best submission best_submission_transactions: type: array items: type: object properties: key: description: >- key is the position (txIdx, blockHash) of this tx on BTC blockchain Although it is already a part of SubmissionKey, we store it here again to make TransactionInfo self-contained. For example, storing the key allows TransactionInfo to not relay on the fact that TransactionInfo will be ordered in the same order as TransactionKeys in SubmissionKey. type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block transaction: type: string format: byte title: transaction is the full transaction in bytes proof: type: string format: byte title: >- proof is the Merkle proof that this tx is included in the position in `key` TODO: maybe it could use here better format as we already processed and valideated the proof? title: >- TransactionInfo is the info of a tx that contains Babylon checkpoint, including - the position of the tx on BTC blockchain - the full tx content - the Merkle proof that this tx is on the above position title: the BTC checkpoint transactions of the best submission best_submission_vigilante_address_list: type: array items: type: object properties: submitter: type: string format: byte description: >- TODO: this could probably be better typed submitter is the address of the checkpoint submitter to BTC, extracted from the checkpoint itself. reporter: type: string format: byte title: >- reporter is the address of the reporter who reported the submissions, calculated from submission message MsgInsertBTCSpvProof itself title: >- CheckpointAddresses contains the addresses of the submitter and reporter of a given checkpoint title: list of vigilantes' addresses of the best submission title: >- BTCCheckpointInfo contains all data about best submission of checkpoint for given epoch. Best submission is the submission which is deeper in btc ledger title: |- QueryBtcCheckpointInfoResponse is response type for the Query/BtcCheckpointInfo RPC method default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: epoch_num description: |- Number of epoch for which the earliest checkpointing btc height is requested in: path required: true type: string format: uint64 tags: - Query /babylon/btccheckpoint/v1/{epoch_num}/submissions: get: summary: EpochSubmissions returns all submissions for a given epoch operationId: EpochSubmissions responses: '200': description: A successful response. schema: type: object properties: keys: type: array items: type: object properties: key: type: array items: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block title: >- Checkpoint can be composed from multiple transactions, so to identify whole submission we need list of transaction keys. Each submission can generally be identified by this list of (txIdx, blockHash) tuples. Note: this could possibly be optimized as if transactions were in one block they would have the same block hash and different indexes, but each blockhash is only 33 (1 byte for prefix encoding and 32 byte hash), so there should be other strong arguments for this optimization description: All submissions saved during an epoch. pagination: type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: >- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: >- QueryEpochSubmissionsResponse defines a response to get all submissions in given epoch (QueryEpochSubmissionsRequest) default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: epoch_num description: Number of epoch for which submissions are requested in: path required: true type: string format: uint64 - name: pagination.key description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. in: query required: false type: string format: byte - name: pagination.offset description: >- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. in: query required: false type: string format: uint64 - name: pagination.limit description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. in: query required: false type: string format: uint64 - name: pagination.count_total description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. in: query required: false type: boolean - name: pagination.reverse description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 in: query required: false type: boolean tags: - Query /babylon/btclightclient/v1/baseheader: get: summary: >- BaseHeader returns the base BTC header of the chain. This header is defined on genesis. operationId: BaseHeader responses: '200': description: A successful response. schema: type: object properties: header: type: object properties: header: type: string format: byte hash: type: string format: byte height: type: string format: uint64 work: type: string format: byte description: >- BTCHeaderInfo is a structure that contains all relevant information about a BTC header - Full header bytes - Header hash for easy retrieval - Height of the header in the BTC chain - Total work spent on the header. This is the sum of the work corresponding to the header Bits field and the total work of the header. description: >- QueryBaseHeaderResponse is the response type for the Query/BaseHeader RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte tags: - Query /babylon/btclightclient/v1/contains: get: summary: Contains checks whether a hash is maintained by the module. operationId: Contains responses: '200': description: A successful response. schema: type: object properties: contains: type: boolean description: >- QueryContainsResponse is response type for the Query/Contains RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: hash in: query required: false type: string format: byte tags: - Query /babylon/btclightclient/v1/containsBytes: get: summary: |- ContainsBytes is a temporary method that checks whether a hash is maintained by the module. See discussion at https://github.com/babylonchain/babylon/pull/132 for more details. operationId: ContainsBytes responses: '200': description: A successful response. schema: type: object properties: contains: type: boolean description: >- QueryContainsResponse is response type for the temporary Query/ContainsBytes RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: hash in: query required: false type: string format: byte tags: - Query /babylon/btclightclient/v1/hashes: get: summary: Hashes retrieves the hashes maintained by the module. operationId: Hashes responses: '200': description: A successful response. schema: type: object properties: hashes: type: array items: type: string format: byte pagination: type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: >- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } description: >- QueryHashesResponse is response type for the Query/Hashes RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: pagination.key description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. in: query required: false type: string format: byte - name: pagination.offset description: >- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. in: query required: false type: string format: uint64 - name: pagination.limit description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. in: query required: false type: string format: uint64 - name: pagination.count_total description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. in: query required: false type: boolean - name: pagination.reverse description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 in: query required: false type: boolean tags: - Query /babylon/btclightclient/v1/mainchain: get: summary: MainChain returns the canonical chain operationId: MainChain responses: '200': description: A successful response. schema: type: object properties: headers: type: array items: type: object properties: header: type: string format: byte hash: type: string format: byte height: type: string format: uint64 work: type: string format: byte description: >- BTCHeaderInfo is a structure that contains all relevant information about a BTC header - Full header bytes - Header hash for easy retrieval - Height of the header in the BTC chain - Total work spent on the header. This is the sum of the work corresponding to the header Bits field and the total work of the header. pagination: type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: >- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } description: >- QueryMainChainResponse is response type for the Query/MainChain RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: pagination.key description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. in: query required: false type: string format: byte - name: pagination.offset description: >- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. in: query required: false type: string format: uint64 - name: pagination.limit description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. in: query required: false type: string format: uint64 - name: pagination.count_total description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. in: query required: false type: boolean - name: pagination.reverse description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 in: query required: false type: boolean tags: - Query /babylon/btclightclient/v1/tip: get: summary: Tip return best header on canonical chain operationId: Tip responses: '200': description: A successful response. schema: type: object properties: header: type: object properties: header: type: string format: byte hash: type: string format: byte height: type: string format: uint64 work: type: string format: byte description: >- BTCHeaderInfo is a structure that contains all relevant information about a BTC header - Full header bytes - Header hash for easy retrieval - Height of the header in the BTC chain - Total work spent on the header. This is the sum of the work corresponding to the header Bits field and the total work of the header. description: >- QueryTipResponse is the response type for the Query/Tip RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte tags: - Query /babylon/epoching/v1/current_epoch: get: summary: CurrentEpoch queries the current epoch operationId: CurrentEpoch responses: '200': description: A successful response. schema: type: object properties: current_epoch: type: string format: uint64 title: current_epoch is the current epoch number epoch_boundary: type: string format: uint64 title: epoch_boundary is the height of this epoch's last block title: >- QueryCurrentEpochResponse is the response type for the Query/CurrentEpoch RPC method default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } tags: - Query /babylon/epoching/v1/delegation_lifecycle/{del_addr}: get: summary: DelegationLifecycle queries the lifecycle of a given delegation operationId: DelegationLifecycle responses: '200': description: A successful response. schema: type: object properties: del_life: type: object properties: del_addr: type: string del_life: type: array items: type: object properties: state: type: string enum: - CREATED - BONDED - UNBONDING - UNBONDED - REMOVED default: CREATED description: >- - CREATED: CREATED is when the validator/delegation has been created - BONDED: CREATED is when the validator/delegation has become bonded - UNBONDING: CREATED is when the validator/delegation has become unbonding - UNBONDED: CREATED is when the validator/delegation has become unbonded - REMOVED: CREATED is when the validator/delegation has been removed title: >- BondState is the bond state of a validator or delegation val_addr: type: string block_height: type: string format: uint64 block_time: type: string format: date-time title: >- DelegationStateUpdate is the message that records a state update of a delegation title: >- ValidatorLifecycle is a message that records records the lifecycle of a delegation title: |- QueryDelegationLifecycleRequest is the response type for the Query/DelegationLifecycle RPC method default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: del_addr in: path required: true type: string tags: - Query /babylon/epoching/v1/epochs: get: summary: >- EpochsInfo queries the metadata of epochs in a given range, depending on the parameters in the pagination request. Th main use case will be querying the latest epochs in time order. operationId: EpochsInfo responses: '200': description: A successful response. schema: type: object properties: epochs: type: array items: type: object properties: epoch_number: type: string format: uint64 current_epoch_interval: type: string format: uint64 first_block_height: type: string format: uint64 last_block_header: description: >- last_block_header is the header of the last block in this epoch. Babylon needs to remember the last header of each epoch to complete unbonding validators/delegations when a previous epoch's checkpoint is finalised. The last_block_header field is nil in the epoch's beginning, and is set upon the end of this epoch. type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte app_hash_root: type: string format: byte title: >- app_hash_root is the Merkle root of all AppHashs in this epoch It will be used for proving a block is in an epoch sealer_header: title: >- sealer_header is the 2nd header of the next epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. title: Epoch is a structure that contains the metadata of an epoch pagination: title: pagination defines the pagination in the response type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: >- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: >- QueryEpochsInfoResponse is the response type for the Query/EpochInfos method default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: pagination.key description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. in: query required: false type: string format: byte - name: pagination.offset description: >- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. in: query required: false type: string format: uint64 - name: pagination.limit description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. in: query required: false type: string format: uint64 - name: pagination.count_total description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. in: query required: false type: boolean - name: pagination.reverse description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 in: query required: false type: boolean tags: - Query /babylon/epoching/v1/epochs/{epoch_num}: get: summary: EpochInfo queries the information of a given epoch operationId: EpochInfo responses: '200': description: A successful response. schema: type: object properties: epoch: type: object properties: epoch_number: type: string format: uint64 current_epoch_interval: type: string format: uint64 first_block_height: type: string format: uint64 last_block_header: description: >- last_block_header is the header of the last block in this epoch. Babylon needs to remember the last header of each epoch to complete unbonding validators/delegations when a previous epoch's checkpoint is finalised. The last_block_header field is nil in the epoch's beginning, and is set upon the end of this epoch. type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte app_hash_root: type: string format: byte title: >- app_hash_root is the Merkle root of all AppHashs in this epoch It will be used for proving a block is in an epoch sealer_header: title: >- sealer_header is the 2nd header of the next epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. title: Epoch is a structure that contains the metadata of an epoch title: >- QueryEpochInfoRequest is the response type for the Query/EpochInfo method default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: epoch_num in: path required: true type: string format: uint64 tags: - Query /babylon/epoching/v1/epochs/{epoch_num}/messages: get: summary: EpochMsgs queries the messages of a given epoch operationId: EpochMsgs responses: '200': description: A successful response. schema: type: object properties: msgs: type: array items: type: object properties: tx_id: type: string format: byte title: tx_id is the ID of the tx that contains the message msg_id: type: string format: byte title: >- msg_id is the original message ID, i.e., hash of the marshaled message block_height: type: string format: uint64 title: >- block_height is the height when this msg is submitted to Babylon block_time: type: string format: date-time title: >- block_time is the timestamp when this msg is submitted to Babylon msg_create_validator: type: object properties: description: type: object properties: moniker: type: string description: >- moniker defines a human-readable name for the validator. identity: type: string description: >- identity defines an optional identity signature (ex. UPort or Keybase). website: type: string description: website defines an optional website link. security_contact: type: string description: >- security_contact defines an optional email for security contact. details: type: string description: details define other optional details. description: Description defines a validator description. commission: type: object properties: rate: type: string description: >- rate is the commission rate charged to delegators, as a fraction. max_rate: type: string description: >- max_rate defines the maximum commission rate which validator can ever charge, as a fraction. max_change_rate: type: string description: >- max_change_rate defines the maximum daily increase of the validator commission, as a fraction. description: >- CommissionRates defines the initial commission rates to be used for creating a validator. min_self_delegation: type: string delegator_address: type: string validator_address: type: string pubkey: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } value: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgCreateValidator defines a SDK message for creating a new validator. msg_delegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgDelegate defines a SDK message for performing a delegation of coins from a delegator to a validator. msg_undelegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgUndelegate defines a SDK message for performing an undelegation from a delegate and a validator. msg_begin_redelegate: type: object properties: delegator_address: type: string validator_src_address: type: string validator_dst_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgBeginRedelegate defines a SDK message for performing a redelegation of coins from a delegator and source validator to a destination validator. title: >- QueuedMessage is a message that can change the validator set and is delayed to the epoch boundary title: msgs is the list of messages queued in the current epoch pagination: title: pagination defines the pagination in the response type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: >- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: >- QueryEpochMsgsResponse is the response type for the Query/EpochMsgs RPC method default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: epoch_num description: epoch_num is the number of epoch of the requested msg queue in: path required: true type: string format: uint64 - name: pagination.key description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. in: query required: false type: string format: byte - name: pagination.offset description: >- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. in: query required: false type: string format: uint64 - name: pagination.limit description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. in: query required: false type: string format: uint64 - name: pagination.count_total description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. in: query required: false type: boolean - name: pagination.reverse description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 in: query required: false type: boolean tags: - Query /babylon/epoching/v1/epochs/{epoch_num}/validator_set: get: summary: EpochValSet queries the validator set of a given epoch operationId: EpochValSet responses: '200': description: A successful response. schema: type: object properties: validators: type: array items: type: object properties: addr: type: string format: byte title: addr is the validator's address (in sdk.ValAddress) power: type: string format: int64 title: power is the validator's voting power title: Validator is a message that denotes a validator total_voting_power: type: string format: int64 pagination: type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: >- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: >- QueryEpochValSetRequest is the response type for the Query/EpochValSet RPC method default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: epoch_num in: path required: true type: string format: uint64 - name: pagination.key description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. in: query required: false type: string format: byte - name: pagination.offset description: >- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. in: query required: false type: string format: uint64 - name: pagination.limit description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. in: query required: false type: string format: uint64 - name: pagination.count_total description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. in: query required: false type: boolean - name: pagination.reverse description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 in: query required: false type: boolean tags: - Query /babylon/epoching/v1/epochs:latest/messages: get: summary: >- LatestEpochMsgs queries the messages within a given number of most recent epochs operationId: LatestEpochMsgs responses: '200': description: A successful response. schema: type: object properties: latest_epoch_msgs: type: array items: type: object properties: epoch_number: type: string format: uint64 msgs: type: array items: type: object properties: tx_id: type: string format: byte title: >- tx_id is the ID of the tx that contains the message msg_id: type: string format: byte title: >- msg_id is the original message ID, i.e., hash of the marshaled message block_height: type: string format: uint64 title: >- block_height is the height when this msg is submitted to Babylon block_time: type: string format: date-time title: >- block_time is the timestamp when this msg is submitted to Babylon msg_create_validator: type: object properties: description: type: object properties: moniker: type: string description: >- moniker defines a human-readable name for the validator. identity: type: string description: >- identity defines an optional identity signature (ex. UPort or Keybase). website: type: string description: website defines an optional website link. security_contact: type: string description: >- security_contact defines an optional email for security contact. details: type: string description: details define other optional details. description: Description defines a validator description. commission: type: object properties: rate: type: string description: >- rate is the commission rate charged to delegators, as a fraction. max_rate: type: string description: >- max_rate defines the maximum commission rate which validator can ever charge, as a fraction. max_change_rate: type: string description: >- max_change_rate defines the maximum daily increase of the validator commission, as a fraction. description: >- CommissionRates defines the initial commission rates to be used for creating a validator. min_self_delegation: type: string delegator_address: type: string validator_address: type: string pubkey: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } value: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgCreateValidator defines a SDK message for creating a new validator. msg_delegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgDelegate defines a SDK message for performing a delegation of coins from a delegator to a validator. msg_undelegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgUndelegate defines a SDK message for performing an undelegation from a delegate and a validator. msg_begin_redelegate: type: object properties: delegator_address: type: string validator_src_address: type: string validator_dst_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgBeginRedelegate defines a SDK message for performing a redelegation of coins from a delegator and source validator to a destination validator. title: >- QueuedMessage is a message that can change the validator set and is delayed to the epoch boundary title: >- QueuedMessageList is a message that contains a list of staking-related messages queued for an epoch title: >- epoch_msg_map is a list of QueuedMessageList each QueuedMessageList has a field identifying the epoch number pagination: type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: >- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: |- QueryLatestEpochMsgsResponse is the response type for the Query/LatestEpochMsgs RPC method default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: end_epoch description: end_epoch is the number of the last epoch to query. in: query required: false type: string format: uint64 - name: epoch_count description: epoch_count is the number of epochs to query. in: query required: false type: string format: uint64 - name: pagination.key description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. in: query required: false type: string format: byte - name: pagination.offset description: >- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. in: query required: false type: string format: uint64 - name: pagination.limit description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. in: query required: false type: string format: uint64 - name: pagination.count_total description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. in: query required: false type: boolean - name: pagination.reverse description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 in: query required: false type: boolean tags: - Query /babylon/epoching/v1/params: get: summary: Params queries the parameters of the module. operationId: EpochingParams responses: '200': description: A successful response. schema: type: object properties: params: description: params holds all the parameters of this module. type: object properties: epoch_interval: type: string format: uint64 title: >- epoch_interval is the number of consecutive blocks to form an epoch description: >- QueryParamsResponse is the response type for the Query/Params RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } tags: - Query /babylon/epoching/v1/validator_lifecycle/{val_addr}: get: summary: ValidatorLifecycle queries the lifecycle of a given validator operationId: ValidatorLifecycle responses: '200': description: A successful response. schema: type: object properties: val_life: type: object properties: val_addr: type: string val_life: type: array items: type: object properties: state: type: string enum: - CREATED - BONDED - UNBONDING - UNBONDED - REMOVED default: CREATED description: >- - CREATED: CREATED is when the validator/delegation has been created - BONDED: CREATED is when the validator/delegation has become bonded - UNBONDING: CREATED is when the validator/delegation has become unbonding - UNBONDED: CREATED is when the validator/delegation has become unbonded - REMOVED: CREATED is when the validator/delegation has been removed title: >- BondState is the bond state of a validator or delegation block_height: type: string format: uint64 block_time: type: string format: date-time title: >- ValStateUpdate is a messages that records a state update of a validator title: >- ValidatorLifecycle is a message that records records the lifecycle of a validator title: |- QueryValidatorLifecycleResponse is the response type for the Query/ValidatorLifecycle RPC method default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: val_addr in: path required: true type: string tags: - Query /babylon/checkpointing/v1/bls_public_keys/{epoch_num}: get: summary: >- BlsPublicKeyList queries a list of bls public keys of the validators at a given epoch number. operationId: BlsPublicKeyList responses: '200': description: A successful response. schema: type: object properties: validator_with_bls_keys: type: array items: type: object properties: validator_address: type: string bls_pub_key: type: string format: byte voting_power: type: string format: uint64 title: >- ValidatorWithBlsKey couples validator address, voting power, and its bls public key pagination: description: pagination defines the pagination in the response. type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- QueryBlsPublicKeyListResponse is the response type for the Query/BlsPublicKeys RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: epoch_num description: epoch_num defines the epoch for the queried bls public keys in: path required: true type: string format: uint64 - name: pagination.key description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. in: query required: false type: string format: byte - name: pagination.offset description: >- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. in: query required: false type: string format: uint64 - name: pagination.limit description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. in: query required: false type: string format: uint64 - name: pagination.count_total description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. in: query required: false type: boolean - name: pagination.reverse description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 in: query required: false type: boolean tags: - Query /babylon/checkpointing/v1/epochs/{epoch_num}/status: get: summary: EpochStatus queries the status of the checkpoint at a given epoch operationId: EpochStatus responses: '200': description: A successful response. schema: type: object properties: status: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. description: >- QueryEpochStatusResponse is the response type for the Query/EpochStatus RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: epoch_num in: path required: true type: string format: uint64 tags: - Query /babylon/checkpointing/v1/epochs:status_count: get: summary: |- RecentEpochStatusCount queries the number of epochs with each status in recent epochs operationId: RecentEpochStatusCount responses: '200': description: A successful response. schema: type: object properties: tip_epoch: type: string format: uint64 epoch_count: type: string format: uint64 status_count: type: object additionalProperties: type: string format: uint64 description: |- QueryRecentEpochStatusCountResponse is the response type for the Query/EpochStatusCount RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: epoch_count description: >- epoch_count is the number of the most recent epochs to include in the aggregation. in: query required: false type: string format: uint64 tags: - Query /babylon/checkpointing/v1/last_raw_checkpoint/{status}: get: summary: >- LastCheckpointWithStatus queries the last checkpoint with a given status or a more matured status operationId: LastCheckpointWithStatus responses: '200': description: A successful response. schema: type: object properties: raw_checkpoint: type: object properties: epoch_num: type: string format: uint64 title: >- epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs title: RawCheckpoint wraps the BLS multi sig with meta data description: |- QueryLastCheckpointWithStatusResponse is the response type for the Query/LastCheckpointWithStatus RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: status in: path required: true type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED tags: - Query /babylon/checkpointing/v1/raw_checkpoint/{epoch_num}: get: summary: RawCheckpoint queries a checkpoints at a given epoch number. operationId: RawCheckpoint responses: '200': description: A successful response. schema: type: object properties: raw_checkpoint: type: object properties: ckpt: type: object properties: epoch_num: type: string format: uint64 title: >- epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs title: RawCheckpoint wraps the BLS multi sig with meta data status: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: status defines the status of the checkpoint bls_aggr_pk: type: string format: byte title: bls_aggr_pk defines the aggregated BLS public key power_sum: type: string format: uint64 title: >- power_sum defines the accumulated voting power for the checkpoint lifecycle: type: array items: type: object properties: state: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: >- state defines the event of a state transition towards this state block_height: type: string format: uint64 title: >- block_height is the height of the Babylon block that triggers the state update block_time: type: string format: date-time title: >- block_time is the timestamp in the Babylon block that triggers the state update description: >- CheckpointStateUpdate defines a state transition on the checkpoint. description: >- lifecycle defines the lifecycle of this checkpoint, i.e., each state transition and the time (in both timestamp and block height) of this transition. description: RawCheckpointWithMeta wraps the raw checkpoint with meta data. description: >- QueryRawCheckpointResponse is the response type for the Query/RawCheckpoint RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: epoch_num description: epoch_num defines the epoch for the queried checkpoint in: path required: true type: string format: uint64 tags: - Query /babylon/checkpointing/v1/raw_checkpoints: get: summary: >- RawCheckpoints queries checkpoints for a epoch range specified in pagination params. operationId: RawCheckpoints responses: '200': description: A successful response. schema: type: object properties: raw_checkpoints: type: array items: type: object properties: ckpt: type: object properties: epoch_num: type: string format: uint64 title: >- epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs title: RawCheckpoint wraps the BLS multi sig with meta data status: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: status defines the status of the checkpoint bls_aggr_pk: type: string format: byte title: bls_aggr_pk defines the aggregated BLS public key power_sum: type: string format: uint64 title: >- power_sum defines the accumulated voting power for the checkpoint lifecycle: type: array items: type: object properties: state: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: >- state defines the event of a state transition towards this state block_height: type: string format: uint64 title: >- block_height is the height of the Babylon block that triggers the state update block_time: type: string format: date-time title: >- block_time is the timestamp in the Babylon block that triggers the state update description: >- CheckpointStateUpdate defines a state transition on the checkpoint. description: >- lifecycle defines the lifecycle of this checkpoint, i.e., each state transition and the time (in both timestamp and block height) of this transition. description: >- RawCheckpointWithMeta wraps the raw checkpoint with meta data. title: >- the order is going from the newest to oldest based on the epoch number pagination: description: pagination defines the pagination in the response. type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: >- QueryRawCheckpointsResponse is the response type for the Query/RawCheckpoints RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: pagination.key description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. in: query required: false type: string format: byte - name: pagination.offset description: >- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. in: query required: false type: string format: uint64 - name: pagination.limit description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. in: query required: false type: string format: uint64 - name: pagination.count_total description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. in: query required: false type: boolean - name: pagination.reverse description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 in: query required: false type: boolean tags: - Query /babylon/checkpointing/v1/raw_checkpoints/{status}: get: summary: RawCheckpointList queries all checkpoints that match the given status. operationId: RawCheckpointList responses: '200': description: A successful response. schema: type: object properties: raw_checkpoints: type: array items: type: object properties: ckpt: type: object properties: epoch_num: type: string format: uint64 title: >- epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs title: RawCheckpoint wraps the BLS multi sig with meta data status: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: status defines the status of the checkpoint bls_aggr_pk: type: string format: byte title: bls_aggr_pk defines the aggregated BLS public key power_sum: type: string format: uint64 title: >- power_sum defines the accumulated voting power for the checkpoint lifecycle: type: array items: type: object properties: state: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: >- state defines the event of a state transition towards this state block_height: type: string format: uint64 title: >- block_height is the height of the Babylon block that triggers the state update block_time: type: string format: date-time title: >- block_time is the timestamp in the Babylon block that triggers the state update description: >- CheckpointStateUpdate defines a state transition on the checkpoint. description: >- lifecycle defines the lifecycle of this checkpoint, i.e., each state transition and the time (in both timestamp and block height) of this transition. description: >- RawCheckpointWithMeta wraps the raw checkpoint with meta data. title: >- the order is going from the newest to oldest based on the epoch number pagination: description: pagination defines the pagination in the response. type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- QueryRawCheckpointListResponse is the response type for the Query/RawCheckpoints RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string value: type: string format: byte parameters: - name: status description: status defines the status of the raw checkpoints of the query in: path required: true type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED - name: pagination.key description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. in: query required: false type: string format: byte - name: pagination.offset description: >- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. in: query required: false type: string format: uint64 - name: pagination.limit description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. in: query required: false type: string format: uint64 - name: pagination.count_total description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. in: query required: false type: boolean - name: pagination.reverse description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 in: query required: false type: boolean tags: - Query /babylon/zoneconcierge/v1/chain_info/{chain_id}/header/{height}: get: summary: Header queries the CZ header and fork headers at a given height. operationId: Header responses: '200': description: A successful response. schema: type: object properties: header: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header fork_headers: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: >- blocks is the list of non-canonical indexed headers at the same height description: >- Forks is a list of non-canonical `IndexedHeader`s at the same height. For example, assuming the following blockchain ``` A <- B <- C <- D <- E \ -- D1 \ -- D2 ``` Then the fork will be {[D1, D2]} where each item is in struct `IndexedBlock`. Note that each `IndexedHeader` in the fork should have a valid quorum certificate. Such forks exist since Babylon considers CZs might have dishonest majority. Also note that the IBC-Go implementation will only consider the first header in a fork valid, since the subsequent headers cannot be verified without knowing the validator set in the previous header. description: >- QueryHeaderResponse is response type for the Query/Header RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: chain_id in: path required: true type: string - name: height in: path required: true type: string format: uint64 tags: - Query /babylon/zoneconcierge/v1/chains: get: summary: ChainList queries the list of chains that checkpoint to Babylon operationId: ChainList responses: '200': description: A successful response. schema: type: object properties: chain_ids: type: array items: type: string title: >- chain_ids are IDs of the chains in ascending alphabetical order pagination: title: pagination defines the pagination in the response type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: >- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: >- QueryChainListResponse is response type for the Query/ChainList RPC method default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: pagination.key description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. in: query required: false type: string format: byte - name: pagination.offset description: >- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. in: query required: false type: string format: uint64 - name: pagination.limit description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. in: query required: false type: string format: uint64 - name: pagination.count_total description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. in: query required: false type: boolean - name: pagination.reverse description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 in: query required: false type: boolean tags: - Query /babylon/zoneconcierge/v1/chains_info: get: summary: >- ChainsInfo queries the latest info for a given list of chains in Babylon's view operationId: ChainsInfo responses: '200': description: A successful response. schema: type: object properties: chains_info: type: array items: type: object properties: chain_id: type: string title: chain_id is the ID of the chain latest_header: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header latest_forks: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: >- hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: >- Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: >- blocks is the list of non-canonical indexed headers at the same height description: >- Forks is a list of non-canonical `IndexedHeader`s at the same height. For example, assuming the following blockchain ``` A <- B <- C <- D <- E \ -- D1 \ -- D2 ``` Then the fork will be {[D1, D2]} where each item is in struct `IndexedBlock`. Note that each `IndexedHeader` in the fork should have a valid quorum certificate. Such forks exist since Babylon considers CZs might have dishonest majority. Also note that the IBC-Go implementation will only consider the first header in a fork valid, since the subsequent headers cannot be verified without knowing the validator set in the previous header. title: >- latest_forks is the latest forks, formed as a series of IndexedHeader (from low to high) timestamped_headers_count: type: string format: uint64 title: >- timestamped_headers_count is the number of timestamped headers in CZ's canonical chain title: ChainInfo is the information of a CZ description: >- QueryChainsInfoResponse is response type for the Query/ChainsInfo RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: chain_ids in: query required: false type: array items: type: string collectionFormat: multi tags: - Query /babylon/zoneconcierge/v1/epoch_chains_info: get: summary: |- EpochChainsInfo queries the latest info for a list of chains in a given epoch in Babylon's view operationId: EpochChainsInfo responses: '200': description: A successful response. schema: type: object properties: chains_info: type: array items: type: object properties: chain_id: type: string title: chain_id is the ID of the chain latest_header: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header latest_forks: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: >- hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: >- Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: >- blocks is the list of non-canonical indexed headers at the same height description: >- Forks is a list of non-canonical `IndexedHeader`s at the same height. For example, assuming the following blockchain ``` A <- B <- C <- D <- E \ -- D1 \ -- D2 ``` Then the fork will be {[D1, D2]} where each item is in struct `IndexedBlock`. Note that each `IndexedHeader` in the fork should have a valid quorum certificate. Such forks exist since Babylon considers CZs might have dishonest majority. Also note that the IBC-Go implementation will only consider the first header in a fork valid, since the subsequent headers cannot be verified without knowing the validator set in the previous header. title: >- latest_forks is the latest forks, formed as a series of IndexedHeader (from low to high) timestamped_headers_count: type: string format: uint64 title: >- timestamped_headers_count is the number of timestamped headers in CZ's canonical chain title: ChainInfo is the information of a CZ title: chain_info is the info of the CZ description: >- QueryEpochChainsInfoResponse is response type for the Query/EpochChainsInfo RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: epoch_num in: query required: false type: string format: uint64 - name: chain_ids in: query required: false type: array items: type: string collectionFormat: multi tags: - Query /babylon/zoneconcierge/v1/finalized_chain_info/{chain_id}/height/{height}: get: summary: >- FinalizedChainInfoUntilHeight queries the BTC-finalised info no later than the provided CZ height, with proofs operationId: FinalizedChainInfoUntilHeight responses: '200': description: A successful response. schema: type: object properties: finalized_chain_info: type: object properties: chain_id: type: string title: chain_id is the ID of the chain latest_header: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header latest_forks: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: >- hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: >- blocks is the list of non-canonical indexed headers at the same height description: >- Forks is a list of non-canonical `IndexedHeader`s at the same height. For example, assuming the following blockchain ``` A <- B <- C <- D <- E \ -- D1 \ -- D2 ``` Then the fork will be {[D1, D2]} where each item is in struct `IndexedBlock`. Note that each `IndexedHeader` in the fork should have a valid quorum certificate. Such forks exist since Babylon considers CZs might have dishonest majority. Also note that the IBC-Go implementation will only consider the first header in a fork valid, since the subsequent headers cannot be verified without knowing the validator set in the previous header. title: >- latest_forks is the latest forks, formed as a series of IndexedHeader (from low to high) timestamped_headers_count: type: string format: uint64 title: >- timestamped_headers_count is the number of timestamped headers in CZ's canonical chain title: ChainInfo is the information of a CZ epoch_info: title: epoch_info is the metadata of the last BTC-finalised epoch type: object properties: epoch_number: type: string format: uint64 current_epoch_interval: type: string format: uint64 first_block_height: type: string format: uint64 last_block_header: description: >- last_block_header is the header of the last block in this epoch. Babylon needs to remember the last header of each epoch to complete unbonding validators/delegations when a previous epoch's checkpoint is finalised. The last_block_header field is nil in the epoch's beginning, and is set upon the end of this epoch. type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte app_hash_root: type: string format: byte title: >- app_hash_root is the Merkle root of all AppHashs in this epoch It will be used for proving a block is in an epoch sealer_header: title: >- sealer_header is the 2nd header of the next epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. raw_checkpoint: title: raw_checkpoint is the raw checkpoint of this epoch type: object properties: epoch_num: type: string format: uint64 title: >- epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs btc_submission_key: title: >- btc_submission_key is position of two BTC txs that include the raw checkpoint of this epoch type: object properties: key: type: array items: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block proof: title: proof is the proof that the chain info is finalized type: object properties: proof_tx_in_block: title: >- proof_tx_in_block is the proof that tx that carries the header is included in a certain Babylon block type: object properties: root_hash: type: string format: byte data: type: string format: byte proof: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte description: >- TxProof represents a Merkle proof of the presence of a transaction in the Merkle tree. proof_header_in_epoch: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte title: >- proof_header_in_epoch is the proof that the Babylon header is in a certain epoch proof_epoch_sealed: title: proof_epoch_sealed is the proof that the epoch is sealed type: object properties: validator_set: type: array items: type: object properties: validator_address: type: string bls_pub_key: type: string format: byte voting_power: type: string format: uint64 title: >- ValidatorWithBlsKey couples validator address, voting power, and its bls public key title: >- validator_set is the validator set of the sealed epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header proof_epoch_info: title: >- proof_epoch_info is the Merkle proof that the epoch's metadata is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: >- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash proof_epoch_val_set: title: >- proof_epoch_info is the Merkle proof that the epoch's validator set is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: >- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash proof_epoch_submitted: type: array items: type: object properties: key: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block description: >- key is the position (txIdx, blockHash) of this tx on BTC blockchain Although it is already a part of SubmissionKey, we store it here again to make TransactionInfo self-contained. For example, storing the key allows TransactionInfo to not relay on the fact that TransactionInfo will be ordered in the same order as TransactionKeys in SubmissionKey. transaction: type: string format: byte title: transaction is the full transaction in bytes proof: type: string format: byte title: >- proof is the Merkle proof that this tx is included in the position in `key` TODO: maybe it could use here better format as we already processed and valideated the proof? title: >- TransactionInfo is the info of a tx that contains Babylon checkpoint, including - the position of the tx on BTC blockchain - the full tx content - the Merkle proof that this tx is on the above position title: >- proof_epoch_submitted is the proof that the epoch's checkpoint is included in BTC ledger It is the two TransactionInfo in the best (i.e., earliest) checkpoint submission description: >- QueryFinalizedChainInfoUntilHeightResponse is response type for the Query/FinalizedChainInfoUntilHeight RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: chain_id description: chain_id is the ID of the CZ in: path required: true type: string - name: height description: >- height is the height of the CZ chain such that the returned finalised chain info will be no later than this height in: path required: true type: string format: uint64 - name: prove description: >- prove indicates whether the querier wants to get proofs of this timestamp. in: query required: false type: boolean tags: - Query /babylon/zoneconcierge/v1/finalized_chains_info: get: summary: >- FinalizedChainsInfo queries the BTC-finalised info of chains with given IDs, with proofs operationId: FinalizedChainsInfo responses: '200': description: A successful response. schema: type: object properties: finalized_chains_info: type: array items: type: object properties: chain_id: type: string title: chain_id is the ID of the chain finalized_chain_info: type: object properties: chain_id: type: string title: chain_id is the ID of the chain latest_header: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: >- hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header latest_forks: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: >- hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: >- Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: >- blocks is the list of non-canonical indexed headers at the same height description: >- Forks is a list of non-canonical `IndexedHeader`s at the same height. For example, assuming the following blockchain ``` A <- B <- C <- D <- E \ -- D1 \ -- D2 ``` Then the fork will be {[D1, D2]} where each item is in struct `IndexedBlock`. Note that each `IndexedHeader` in the fork should have a valid quorum certificate. Such forks exist since Babylon considers CZs might have dishonest majority. Also note that the IBC-Go implementation will only consider the first header in a fork valid, since the subsequent headers cannot be verified without knowing the validator set in the previous header. title: >- latest_forks is the latest forks, formed as a series of IndexedHeader (from low to high) timestamped_headers_count: type: string format: uint64 title: >- timestamped_headers_count is the number of timestamped headers in CZ's canonical chain title: ChainInfo is the information of a CZ epoch_info: title: >- epoch_info is the metadata of the last BTC-finalised epoch type: object properties: epoch_number: type: string format: uint64 current_epoch_interval: type: string format: uint64 first_block_height: type: string format: uint64 last_block_header: description: >- last_block_header is the header of the last block in this epoch. Babylon needs to remember the last header of each epoch to complete unbonding validators/delegations when a previous epoch's checkpoint is finalised. The last_block_header field is nil in the epoch's beginning, and is set upon the end of this epoch. type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte app_hash_root: type: string format: byte title: >- app_hash_root is the Merkle root of all AppHashs in this epoch It will be used for proving a block is in an epoch sealer_header: title: >- sealer_header is the 2nd header of the next epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. raw_checkpoint: title: raw_checkpoint is the raw checkpoint of this epoch type: object properties: epoch_num: type: string format: uint64 title: >- epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs btc_submission_key: title: >- btc_submission_key is position of two BTC txs that include the raw checkpoint of this epoch type: object properties: key: type: array items: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block proof: title: proof is the proof that the chain info is finalized type: object properties: proof_tx_in_block: title: >- proof_tx_in_block is the proof that tx that carries the header is included in a certain Babylon block type: object properties: root_hash: type: string format: byte data: type: string format: byte proof: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte description: >- TxProof represents a Merkle proof of the presence of a transaction in the Merkle tree. proof_header_in_epoch: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte title: >- proof_header_in_epoch is the proof that the Babylon header is in a certain epoch proof_epoch_sealed: title: >- proof_epoch_sealed is the proof that the epoch is sealed type: object properties: validator_set: type: array items: type: object properties: validator_address: type: string bls_pub_key: type: string format: byte voting_power: type: string format: uint64 title: >- ValidatorWithBlsKey couples validator address, voting power, and its bls public key title: >- validator_set is the validator set of the sealed epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header proof_epoch_info: title: >- proof_epoch_info is the Merkle proof that the epoch's metadata is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: >- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash proof_epoch_val_set: title: >- proof_epoch_info is the Merkle proof that the epoch's validator set is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: >- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash proof_epoch_submitted: type: array items: type: object properties: key: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block description: >- key is the position (txIdx, blockHash) of this tx on BTC blockchain Although it is already a part of SubmissionKey, we store it here again to make TransactionInfo self-contained. For example, storing the key allows TransactionInfo to not relay on the fact that TransactionInfo will be ordered in the same order as TransactionKeys in SubmissionKey. transaction: type: string format: byte title: transaction is the full transaction in bytes proof: type: string format: byte title: >- proof is the Merkle proof that this tx is included in the position in `key` TODO: maybe it could use here better format as we already processed and valideated the proof? title: >- TransactionInfo is the info of a tx that contains Babylon checkpoint, including - the position of the tx on BTC blockchain - the full tx content - the Merkle proof that this tx is on the above position title: >- proof_epoch_submitted is the proof that the epoch's checkpoint is included in BTC ledger It is the two TransactionInfo in the best (i.e., earliest) checkpoint submission title: >- FinalizedChainInfo is the information of a CZ that is BTC-finalised description: |- QueryFinalizedChainsInfoResponse is response type for the Query/FinalizedChainsInfo RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: chain_ids description: chain_ids is the list of ids of CZs. in: query required: false type: array items: type: string collectionFormat: multi - name: prove description: >- prove indicates whether the querier wants to get proofs of this timestamp. in: query required: false type: boolean tags: - Query /babylon/zoneconcierge/v1/headers/{chain_id}: get: summary: |- ListHeaders queries the headers of a chain in Babylon's view, with pagination support operationId: ListHeaders responses: '200': description: A successful response. schema: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: headers is the list of headers pagination: title: pagination defines the pagination in the response type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: >- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } description: >- QueryListHeadersResponse is response type for the Query/ListHeaders RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: chain_id in: path required: true type: string - name: pagination.key description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. in: query required: false type: string format: byte - name: pagination.offset description: >- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. in: query required: false type: string format: uint64 - name: pagination.limit description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. in: query required: false type: string format: uint64 - name: pagination.count_total description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. in: query required: false type: boolean - name: pagination.reverse description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 in: query required: false type: boolean tags: - Query /babylon/zoneconcierge/v1/headers/{chain_id}/epochs/{epoch_num}: get: summary: |- ListEpochHeaders queries the headers of a chain timestamped in a given epoch of Babylon, with pagination support operationId: ListEpochHeaders responses: '200': description: A successful response. schema: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: headers is the list of headers description: >- QueryListEpochHeadersResponse is response type for the Query/ListEpochHeaders RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } parameters: - name: chain_id in: path required: true type: string - name: epoch_num in: path required: true type: string format: uint64 tags: - Query /babylon/zoneconcierge/v1/params: get: summary: Params queries the parameters of the module. operationId: ZoneConciergeParams responses: '200': description: A successful response. schema: type: object properties: params: description: params holds all the parameters of this module. type: object properties: ibc_packet_timeout_seconds: type: integer format: int64 title: >- ibc_packet_timeout_seconds is the time period after which an unrelayed IBC packet becomes timeout, measured in seconds description: >- QueryParamsResponse is the response type for the Query/Params RPC method. default: description: An unexpected error response. schema: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } tags: - Query definitions: babylon.btccheckpoint.v1.BTCCheckpointInfo: type: object properties: epoch_number: type: string format: uint64 title: epoch number of this checkpoint best_submission_btc_block_height: type: string format: uint64 title: btc height of the best submission of the epoch best_submission_btc_block_hash: type: string format: byte title: >- hash of the btc block which determines checkpoint btc block height i.e. youngest block of best submission best_submission_transactions: type: array items: type: object properties: key: description: >- key is the position (txIdx, blockHash) of this tx on BTC blockchain Although it is already a part of SubmissionKey, we store it here again to make TransactionInfo self-contained. For example, storing the key allows TransactionInfo to not relay on the fact that TransactionInfo will be ordered in the same order as TransactionKeys in SubmissionKey. type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block transaction: type: string format: byte title: transaction is the full transaction in bytes proof: type: string format: byte title: >- proof is the Merkle proof that this tx is included in the position in `key` TODO: maybe it could use here better format as we already processed and valideated the proof? title: >- TransactionInfo is the info of a tx that contains Babylon checkpoint, including - the position of the tx on BTC blockchain - the full tx content - the Merkle proof that this tx is on the above position title: the BTC checkpoint transactions of the best submission best_submission_vigilante_address_list: type: array items: type: object properties: submitter: type: string format: byte description: >- TODO: this could probably be better typed submitter is the address of the checkpoint submitter to BTC, extracted from the checkpoint itself. reporter: type: string format: byte title: >- reporter is the address of the reporter who reported the submissions, calculated from submission message MsgInsertBTCSpvProof itself title: >- CheckpointAddresses contains the addresses of the submitter and reporter of a given checkpoint title: list of vigilantes' addresses of the best submission title: >- BTCCheckpointInfo contains all data about best submission of checkpoint for given epoch. Best submission is the submission which is deeper in btc ledger babylon.btccheckpoint.v1.CheckpointAddresses: type: object properties: submitter: type: string format: byte description: >- TODO: this could probably be better typed submitter is the address of the checkpoint submitter to BTC, extracted from the checkpoint itself. reporter: type: string format: byte title: |- reporter is the address of the reporter who reported the submissions, calculated from submission message MsgInsertBTCSpvProof itself title: >- CheckpointAddresses contains the addresses of the submitter and reporter of a given checkpoint babylon.btccheckpoint.v1.Params: type: object properties: btc_confirmation_depth: type: string format: uint64 title: >- btc_confirmation_depth is the confirmation depth in BTC. A block is considered irreversible only when it is at least k-deep in BTC (k in research paper) checkpoint_finalization_timeout: type: string format: uint64 title: >- checkpoint_finalization_timeout is the maximum time window (measured in BTC blocks) between a checkpoint - being submitted to BTC, and - being reported back to BBN If a checkpoint has not been reported back within w BTC blocks, then BBN has dishonest majority and is stalling checkpoints (w in research paper) checkpoint_tag: type: string title: >- 4byte tag in hex format, required to be present in the OP_RETURN transaction related to babylon description: Params defines the parameters for the module. babylon.btccheckpoint.v1.QueryBtcCheckpointInfoResponse: type: object properties: info: type: object properties: epoch_number: type: string format: uint64 title: epoch number of this checkpoint best_submission_btc_block_height: type: string format: uint64 title: btc height of the best submission of the epoch best_submission_btc_block_hash: type: string format: byte title: >- hash of the btc block which determines checkpoint btc block height i.e. youngest block of best submission best_submission_transactions: type: array items: type: object properties: key: description: >- key is the position (txIdx, blockHash) of this tx on BTC blockchain Although it is already a part of SubmissionKey, we store it here again to make TransactionInfo self-contained. For example, storing the key allows TransactionInfo to not relay on the fact that TransactionInfo will be ordered in the same order as TransactionKeys in SubmissionKey. type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block transaction: type: string format: byte title: transaction is the full transaction in bytes proof: type: string format: byte title: >- proof is the Merkle proof that this tx is included in the position in `key` TODO: maybe it could use here better format as we already processed and valideated the proof? title: >- TransactionInfo is the info of a tx that contains Babylon checkpoint, including - the position of the tx on BTC blockchain - the full tx content - the Merkle proof that this tx is on the above position title: the BTC checkpoint transactions of the best submission best_submission_vigilante_address_list: type: array items: type: object properties: submitter: type: string format: byte description: >- TODO: this could probably be better typed submitter is the address of the checkpoint submitter to BTC, extracted from the checkpoint itself. reporter: type: string format: byte title: >- reporter is the address of the reporter who reported the submissions, calculated from submission message MsgInsertBTCSpvProof itself title: >- CheckpointAddresses contains the addresses of the submitter and reporter of a given checkpoint title: list of vigilantes' addresses of the best submission title: >- BTCCheckpointInfo contains all data about best submission of checkpoint for given epoch. Best submission is the submission which is deeper in btc ledger title: |- QueryBtcCheckpointInfoResponse is response type for the Query/BtcCheckpointInfo RPC method babylon.btccheckpoint.v1.QueryBtcCheckpointsInfoResponse: type: object properties: info_list: type: array items: type: object properties: epoch_number: type: string format: uint64 title: epoch number of this checkpoint best_submission_btc_block_height: type: string format: uint64 title: btc height of the best submission of the epoch best_submission_btc_block_hash: type: string format: byte title: >- hash of the btc block which determines checkpoint btc block height i.e. youngest block of best submission best_submission_transactions: type: array items: type: object properties: key: description: >- key is the position (txIdx, blockHash) of this tx on BTC blockchain Although it is already a part of SubmissionKey, we store it here again to make TransactionInfo self-contained. For example, storing the key allows TransactionInfo to not relay on the fact that TransactionInfo will be ordered in the same order as TransactionKeys in SubmissionKey. type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block transaction: type: string format: byte title: transaction is the full transaction in bytes proof: type: string format: byte title: >- proof is the Merkle proof that this tx is included in the position in `key` TODO: maybe it could use here better format as we already processed and valideated the proof? title: >- TransactionInfo is the info of a tx that contains Babylon checkpoint, including - the position of the tx on BTC blockchain - the full tx content - the Merkle proof that this tx is on the above position title: the BTC checkpoint transactions of the best submission best_submission_vigilante_address_list: type: array items: type: object properties: submitter: type: string format: byte description: >- TODO: this could probably be better typed submitter is the address of the checkpoint submitter to BTC, extracted from the checkpoint itself. reporter: type: string format: byte title: >- reporter is the address of the reporter who reported the submissions, calculated from submission message MsgInsertBTCSpvProof itself title: >- CheckpointAddresses contains the addresses of the submitter and reporter of a given checkpoint title: list of vigilantes' addresses of the best submission title: >- BTCCheckpointInfo contains all data about best submission of checkpoint for given epoch. Best submission is the submission which is deeper in btc ledger pagination: title: pagination defines the pagination in the response type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: |- QueryBtcCheckpointsInfoResponse is response type for the Query/BtcCheckpointsInfo RPC method babylon.btccheckpoint.v1.QueryEpochSubmissionsResponse: type: object properties: keys: type: array items: type: object properties: key: type: array items: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block title: >- Checkpoint can be composed from multiple transactions, so to identify whole submission we need list of transaction keys. Each submission can generally be identified by this list of (txIdx, blockHash) tuples. Note: this could possibly be optimized as if transactions were in one block they would have the same block hash and different indexes, but each blockhash is only 33 (1 byte for prefix encoding and 32 byte hash), so there should be other strong arguments for this optimization description: All submissions saved during an epoch. pagination: type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: |- QueryEpochSubmissionsResponse defines a response to get all submissions in given epoch (QueryEpochSubmissionsRequest) babylon.btccheckpoint.v1.QueryParamsResponse: type: object properties: params: description: params holds all the parameters of this module. type: object properties: btc_confirmation_depth: type: string format: uint64 title: >- btc_confirmation_depth is the confirmation depth in BTC. A block is considered irreversible only when it is at least k-deep in BTC (k in research paper) checkpoint_finalization_timeout: type: string format: uint64 title: >- checkpoint_finalization_timeout is the maximum time window (measured in BTC blocks) between a checkpoint - being submitted to BTC, and - being reported back to BBN If a checkpoint has not been reported back within w BTC blocks, then BBN has dishonest majority and is stalling checkpoints (w in research paper) checkpoint_tag: type: string title: >- 4byte tag in hex format, required to be present in the OP_RETURN transaction related to babylon description: QueryParamsResponse is response type for the Query/Params RPC method. babylon.btccheckpoint.v1.SubmissionKey: type: object properties: key: type: array items: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block title: >- Checkpoint can be composed from multiple transactions, so to identify whole submission we need list of transaction keys. Each submission can generally be identified by this list of (txIdx, blockHash) tuples. Note: this could possibly be optimized as if transactions were in one block they would have the same block hash and different indexes, but each blockhash is only 33 (1 byte for prefix encoding and 32 byte hash), so there should be other strong arguments for this optimization babylon.btccheckpoint.v1.TransactionInfo: type: object properties: key: description: |- key is the position (txIdx, blockHash) of this tx on BTC blockchain Although it is already a part of SubmissionKey, we store it here again to make TransactionInfo self-contained. For example, storing the key allows TransactionInfo to not relay on the fact that TransactionInfo will be ordered in the same order as TransactionKeys in SubmissionKey. type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block transaction: type: string format: byte title: transaction is the full transaction in bytes proof: type: string format: byte title: >- proof is the Merkle proof that this tx is included in the position in `key` TODO: maybe it could use here better format as we already processed and valideated the proof? title: |- TransactionInfo is the info of a tx that contains Babylon checkpoint, including - the position of the tx on BTC blockchain - the full tx content - the Merkle proof that this tx is on the above position babylon.btccheckpoint.v1.TransactionKey: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: |- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block cosmos.base.query.v1beta1.PageRequest: type: object properties: key: type: string format: byte description: |- key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. offset: type: string format: uint64 description: |- offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. limit: type: string format: uint64 description: >- limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. count_total: type: boolean description: >- count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. reverse: type: boolean description: >- reverse is set to true if results are to be returned in the descending order. Since: cosmos-sdk 0.43 description: |- message SomeRequest { Foo some_parameter = 1; PageRequest pagination = 2; } title: |- PageRequest is to be embedded in gRPC request messages for efficient pagination. Ex: cosmos.base.query.v1beta1.PageResponse: type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: |- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } google.protobuf.Any: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } grpc.gateway.runtime.Error: type: object properties: error: type: string code: type: integer format: int32 message: type: string details: type: array items: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } babylon.btclightclient.v1.BTCHeaderInfo: type: object properties: header: type: string format: byte hash: type: string format: byte height: type: string format: uint64 work: type: string format: byte description: >- BTCHeaderInfo is a structure that contains all relevant information about a BTC header - Full header bytes - Header hash for easy retrieval - Height of the header in the BTC chain - Total work spent on the header. This is the sum of the work corresponding to the header Bits field and the total work of the header. babylon.btclightclient.v1.QueryBaseHeaderResponse: type: object properties: header: type: object properties: header: type: string format: byte hash: type: string format: byte height: type: string format: uint64 work: type: string format: byte description: >- BTCHeaderInfo is a structure that contains all relevant information about a BTC header - Full header bytes - Header hash for easy retrieval - Height of the header in the BTC chain - Total work spent on the header. This is the sum of the work corresponding to the header Bits field and the total work of the header. description: |- QueryBaseHeaderResponse is the response type for the Query/BaseHeader RPC method. babylon.btclightclient.v1.QueryContainsBytesResponse: type: object properties: contains: type: boolean description: >- QueryContainsResponse is response type for the temporary Query/ContainsBytes RPC method. babylon.btclightclient.v1.QueryContainsResponse: type: object properties: contains: type: boolean description: QueryContainsResponse is response type for the Query/Contains RPC method. babylon.btclightclient.v1.QueryHashesResponse: type: object properties: hashes: type: array items: type: string format: byte pagination: type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } description: QueryHashesResponse is response type for the Query/Hashes RPC method. babylon.btclightclient.v1.QueryMainChainResponse: type: object properties: headers: type: array items: type: object properties: header: type: string format: byte hash: type: string format: byte height: type: string format: uint64 work: type: string format: byte description: >- BTCHeaderInfo is a structure that contains all relevant information about a BTC header - Full header bytes - Header hash for easy retrieval - Height of the header in the BTC chain - Total work spent on the header. This is the sum of the work corresponding to the header Bits field and the total work of the header. pagination: type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } description: >- QueryMainChainResponse is response type for the Query/MainChain RPC method. babylon.btclightclient.v1.QueryTipResponse: type: object properties: header: type: object properties: header: type: string format: byte hash: type: string format: byte height: type: string format: uint64 work: type: string format: byte description: >- BTCHeaderInfo is a structure that contains all relevant information about a BTC header - Full header bytes - Header hash for easy retrieval - Height of the header in the BTC chain - Total work spent on the header. This is the sum of the work corresponding to the header Bits field and the total work of the header. description: QueryTipResponse is the response type for the Query/Tip RPC method. babylon.epoching.v1.BondState: type: string enum: - CREATED - BONDED - UNBONDING - UNBONDED - REMOVED default: CREATED description: |- - CREATED: CREATED is when the validator/delegation has been created - BONDED: CREATED is when the validator/delegation has become bonded - UNBONDING: CREATED is when the validator/delegation has become unbonding - UNBONDED: CREATED is when the validator/delegation has become unbonded - REMOVED: CREATED is when the validator/delegation has been removed title: BondState is the bond state of a validator or delegation babylon.epoching.v1.DelegationLifecycle: type: object properties: del_addr: type: string del_life: type: array items: type: object properties: state: type: string enum: - CREATED - BONDED - UNBONDING - UNBONDED - REMOVED default: CREATED description: >- - CREATED: CREATED is when the validator/delegation has been created - BONDED: CREATED is when the validator/delegation has become bonded - UNBONDING: CREATED is when the validator/delegation has become unbonding - UNBONDED: CREATED is when the validator/delegation has become unbonded - REMOVED: CREATED is when the validator/delegation has been removed title: BondState is the bond state of a validator or delegation val_addr: type: string block_height: type: string format: uint64 block_time: type: string format: date-time title: >- DelegationStateUpdate is the message that records a state update of a delegation title: |- ValidatorLifecycle is a message that records records the lifecycle of a delegation babylon.epoching.v1.DelegationStateUpdate: type: object properties: state: type: string enum: - CREATED - BONDED - UNBONDING - UNBONDED - REMOVED default: CREATED description: |- - CREATED: CREATED is when the validator/delegation has been created - BONDED: CREATED is when the validator/delegation has become bonded - UNBONDING: CREATED is when the validator/delegation has become unbonding - UNBONDED: CREATED is when the validator/delegation has become unbonded - REMOVED: CREATED is when the validator/delegation has been removed title: BondState is the bond state of a validator or delegation val_addr: type: string block_height: type: string format: uint64 block_time: type: string format: date-time title: |- DelegationStateUpdate is the message that records a state update of a delegation babylon.epoching.v1.Epoch: type: object properties: epoch_number: type: string format: uint64 current_epoch_interval: type: string format: uint64 first_block_height: type: string format: uint64 last_block_header: description: >- last_block_header is the header of the last block in this epoch. Babylon needs to remember the last header of each epoch to complete unbonding validators/delegations when a previous epoch's checkpoint is finalised. The last_block_header field is nil in the epoch's beginning, and is set upon the end of this epoch. type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte app_hash_root: type: string format: byte title: |- app_hash_root is the Merkle root of all AppHashs in this epoch It will be used for proving a block is in an epoch sealer_header: title: >- sealer_header is the 2nd header of the next epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. title: Epoch is a structure that contains the metadata of an epoch babylon.epoching.v1.Params: type: object properties: epoch_interval: type: string format: uint64 title: epoch_interval is the number of consecutive blocks to form an epoch description: Params defines the parameters for the module. babylon.epoching.v1.QueryCurrentEpochResponse: type: object properties: current_epoch: type: string format: uint64 title: current_epoch is the current epoch number epoch_boundary: type: string format: uint64 title: epoch_boundary is the height of this epoch's last block title: >- QueryCurrentEpochResponse is the response type for the Query/CurrentEpoch RPC method babylon.epoching.v1.QueryDelegationLifecycleResponse: type: object properties: del_life: type: object properties: del_addr: type: string del_life: type: array items: type: object properties: state: type: string enum: - CREATED - BONDED - UNBONDING - UNBONDED - REMOVED default: CREATED description: >- - CREATED: CREATED is when the validator/delegation has been created - BONDED: CREATED is when the validator/delegation has become bonded - UNBONDING: CREATED is when the validator/delegation has become unbonding - UNBONDED: CREATED is when the validator/delegation has become unbonded - REMOVED: CREATED is when the validator/delegation has been removed title: BondState is the bond state of a validator or delegation val_addr: type: string block_height: type: string format: uint64 block_time: type: string format: date-time title: >- DelegationStateUpdate is the message that records a state update of a delegation title: |- ValidatorLifecycle is a message that records records the lifecycle of a delegation title: |- QueryDelegationLifecycleRequest is the response type for the Query/DelegationLifecycle RPC method babylon.epoching.v1.QueryEpochInfoResponse: type: object properties: epoch: type: object properties: epoch_number: type: string format: uint64 current_epoch_interval: type: string format: uint64 first_block_height: type: string format: uint64 last_block_header: description: >- last_block_header is the header of the last block in this epoch. Babylon needs to remember the last header of each epoch to complete unbonding validators/delegations when a previous epoch's checkpoint is finalised. The last_block_header field is nil in the epoch's beginning, and is set upon the end of this epoch. type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte app_hash_root: type: string format: byte title: |- app_hash_root is the Merkle root of all AppHashs in this epoch It will be used for proving a block is in an epoch sealer_header: title: >- sealer_header is the 2nd header of the next epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. title: Epoch is a structure that contains the metadata of an epoch title: QueryEpochInfoRequest is the response type for the Query/EpochInfo method babylon.epoching.v1.QueryEpochMsgsResponse: type: object properties: msgs: type: array items: type: object properties: tx_id: type: string format: byte title: tx_id is the ID of the tx that contains the message msg_id: type: string format: byte title: >- msg_id is the original message ID, i.e., hash of the marshaled message block_height: type: string format: uint64 title: block_height is the height when this msg is submitted to Babylon block_time: type: string format: date-time title: >- block_time is the timestamp when this msg is submitted to Babylon msg_create_validator: type: object properties: description: type: object properties: moniker: type: string description: moniker defines a human-readable name for the validator. identity: type: string description: >- identity defines an optional identity signature (ex. UPort or Keybase). website: type: string description: website defines an optional website link. security_contact: type: string description: >- security_contact defines an optional email for security contact. details: type: string description: details define other optional details. description: Description defines a validator description. commission: type: object properties: rate: type: string description: >- rate is the commission rate charged to delegators, as a fraction. max_rate: type: string description: >- max_rate defines the maximum commission rate which validator can ever charge, as a fraction. max_change_rate: type: string description: >- max_change_rate defines the maximum daily increase of the validator commission, as a fraction. description: >- CommissionRates defines the initial commission rates to be used for creating a validator. min_self_delegation: type: string delegator_address: type: string validator_address: type: string pubkey: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } value: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgCreateValidator defines a SDK message for creating a new validator. msg_delegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgDelegate defines a SDK message for performing a delegation of coins from a delegator to a validator. msg_undelegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgUndelegate defines a SDK message for performing an undelegation from a delegate and a validator. msg_begin_redelegate: type: object properties: delegator_address: type: string validator_src_address: type: string validator_dst_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgBeginRedelegate defines a SDK message for performing a redelegation of coins from a delegator and source validator to a destination validator. title: >- QueuedMessage is a message that can change the validator set and is delayed to the epoch boundary title: msgs is the list of messages queued in the current epoch pagination: title: pagination defines the pagination in the response type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: |- QueryEpochMsgsResponse is the response type for the Query/EpochMsgs RPC method babylon.epoching.v1.QueryEpochValSetResponse: type: object properties: validators: type: array items: type: object properties: addr: type: string format: byte title: addr is the validator's address (in sdk.ValAddress) power: type: string format: int64 title: power is the validator's voting power title: Validator is a message that denotes a validator total_voting_power: type: string format: int64 pagination: type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: |- QueryEpochValSetRequest is the response type for the Query/EpochValSet RPC method babylon.epoching.v1.QueryEpochsInfoResponse: type: object properties: epochs: type: array items: type: object properties: epoch_number: type: string format: uint64 current_epoch_interval: type: string format: uint64 first_block_height: type: string format: uint64 last_block_header: description: >- last_block_header is the header of the last block in this epoch. Babylon needs to remember the last header of each epoch to complete unbonding validators/delegations when a previous epoch's checkpoint is finalised. The last_block_header field is nil in the epoch's beginning, and is set upon the end of this epoch. type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte app_hash_root: type: string format: byte title: |- app_hash_root is the Merkle root of all AppHashs in this epoch It will be used for proving a block is in an epoch sealer_header: title: >- sealer_header is the 2nd header of the next epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. title: Epoch is a structure that contains the metadata of an epoch pagination: title: pagination defines the pagination in the response type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: >- QueryEpochsInfoResponse is the response type for the Query/EpochInfos method babylon.epoching.v1.QueryLatestEpochMsgsResponse: type: object properties: latest_epoch_msgs: type: array items: type: object properties: epoch_number: type: string format: uint64 msgs: type: array items: type: object properties: tx_id: type: string format: byte title: tx_id is the ID of the tx that contains the message msg_id: type: string format: byte title: >- msg_id is the original message ID, i.e., hash of the marshaled message block_height: type: string format: uint64 title: >- block_height is the height when this msg is submitted to Babylon block_time: type: string format: date-time title: >- block_time is the timestamp when this msg is submitted to Babylon msg_create_validator: type: object properties: description: type: object properties: moniker: type: string description: >- moniker defines a human-readable name for the validator. identity: type: string description: >- identity defines an optional identity signature (ex. UPort or Keybase). website: type: string description: website defines an optional website link. security_contact: type: string description: >- security_contact defines an optional email for security contact. details: type: string description: details define other optional details. description: Description defines a validator description. commission: type: object properties: rate: type: string description: >- rate is the commission rate charged to delegators, as a fraction. max_rate: type: string description: >- max_rate defines the maximum commission rate which validator can ever charge, as a fraction. max_change_rate: type: string description: >- max_change_rate defines the maximum daily increase of the validator commission, as a fraction. description: >- CommissionRates defines the initial commission rates to be used for creating a validator. min_self_delegation: type: string delegator_address: type: string validator_address: type: string pubkey: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } value: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgCreateValidator defines a SDK message for creating a new validator. msg_delegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgDelegate defines a SDK message for performing a delegation of coins from a delegator to a validator. msg_undelegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgUndelegate defines a SDK message for performing an undelegation from a delegate and a validator. msg_begin_redelegate: type: object properties: delegator_address: type: string validator_src_address: type: string validator_dst_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgBeginRedelegate defines a SDK message for performing a redelegation of coins from a delegator and source validator to a destination validator. title: >- QueuedMessage is a message that can change the validator set and is delayed to the epoch boundary title: >- QueuedMessageList is a message that contains a list of staking-related messages queued for an epoch title: |- epoch_msg_map is a list of QueuedMessageList each QueuedMessageList has a field identifying the epoch number pagination: type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: |- QueryLatestEpochMsgsResponse is the response type for the Query/LatestEpochMsgs RPC method babylon.epoching.v1.QueryParamsResponse: type: object properties: params: description: params holds all the parameters of this module. type: object properties: epoch_interval: type: string format: uint64 title: >- epoch_interval is the number of consecutive blocks to form an epoch description: QueryParamsResponse is the response type for the Query/Params RPC method. babylon.epoching.v1.QueryValidatorLifecycleResponse: type: object properties: val_life: type: object properties: val_addr: type: string val_life: type: array items: type: object properties: state: type: string enum: - CREATED - BONDED - UNBONDING - UNBONDED - REMOVED default: CREATED description: >- - CREATED: CREATED is when the validator/delegation has been created - BONDED: CREATED is when the validator/delegation has become bonded - UNBONDING: CREATED is when the validator/delegation has become unbonding - UNBONDED: CREATED is when the validator/delegation has become unbonded - REMOVED: CREATED is when the validator/delegation has been removed title: BondState is the bond state of a validator or delegation block_height: type: string format: uint64 block_time: type: string format: date-time title: >- ValStateUpdate is a messages that records a state update of a validator title: |- ValidatorLifecycle is a message that records records the lifecycle of a validator title: |- QueryValidatorLifecycleResponse is the response type for the Query/ValidatorLifecycle RPC method babylon.epoching.v1.QueuedMessage: type: object properties: tx_id: type: string format: byte title: tx_id is the ID of the tx that contains the message msg_id: type: string format: byte title: msg_id is the original message ID, i.e., hash of the marshaled message block_height: type: string format: uint64 title: block_height is the height when this msg is submitted to Babylon block_time: type: string format: date-time title: block_time is the timestamp when this msg is submitted to Babylon msg_create_validator: type: object properties: description: type: object properties: moniker: type: string description: moniker defines a human-readable name for the validator. identity: type: string description: >- identity defines an optional identity signature (ex. UPort or Keybase). website: type: string description: website defines an optional website link. security_contact: type: string description: >- security_contact defines an optional email for security contact. details: type: string description: details define other optional details. description: Description defines a validator description. commission: type: object properties: rate: type: string description: >- rate is the commission rate charged to delegators, as a fraction. max_rate: type: string description: >- max_rate defines the maximum commission rate which validator can ever charge, as a fraction. max_change_rate: type: string description: >- max_change_rate defines the maximum daily increase of the validator commission, as a fraction. description: >- CommissionRates defines the initial commission rates to be used for creating a validator. min_self_delegation: type: string delegator_address: type: string validator_address: type: string pubkey: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } value: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: MsgCreateValidator defines a SDK message for creating a new validator. msg_delegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: |- MsgDelegate defines a SDK message for performing a delegation of coins from a delegator to a validator. msg_undelegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgUndelegate defines a SDK message for performing an undelegation from a delegate and a validator. msg_begin_redelegate: type: object properties: delegator_address: type: string validator_src_address: type: string validator_dst_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgBeginRedelegate defines a SDK message for performing a redelegation of coins from a delegator and source validator to a destination validator. title: >- QueuedMessage is a message that can change the validator set and is delayed to the epoch boundary babylon.epoching.v1.QueuedMessageList: type: object properties: epoch_number: type: string format: uint64 msgs: type: array items: type: object properties: tx_id: type: string format: byte title: tx_id is the ID of the tx that contains the message msg_id: type: string format: byte title: >- msg_id is the original message ID, i.e., hash of the marshaled message block_height: type: string format: uint64 title: block_height is the height when this msg is submitted to Babylon block_time: type: string format: date-time title: >- block_time is the timestamp when this msg is submitted to Babylon msg_create_validator: type: object properties: description: type: object properties: moniker: type: string description: moniker defines a human-readable name for the validator. identity: type: string description: >- identity defines an optional identity signature (ex. UPort or Keybase). website: type: string description: website defines an optional website link. security_contact: type: string description: >- security_contact defines an optional email for security contact. details: type: string description: details define other optional details. description: Description defines a validator description. commission: type: object properties: rate: type: string description: >- rate is the commission rate charged to delegators, as a fraction. max_rate: type: string description: >- max_rate defines the maximum commission rate which validator can ever charge, as a fraction. max_change_rate: type: string description: >- max_change_rate defines the maximum daily increase of the validator commission, as a fraction. description: >- CommissionRates defines the initial commission rates to be used for creating a validator. min_self_delegation: type: string delegator_address: type: string validator_address: type: string pubkey: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } value: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgCreateValidator defines a SDK message for creating a new validator. msg_delegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgDelegate defines a SDK message for performing a delegation of coins from a delegator to a validator. msg_undelegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgUndelegate defines a SDK message for performing an undelegation from a delegate and a validator. msg_begin_redelegate: type: object properties: delegator_address: type: string validator_src_address: type: string validator_dst_address: type: string amount: type: object properties: denom: type: string amount: type: string description: >- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: >- MsgBeginRedelegate defines a SDK message for performing a redelegation of coins from a delegator and source validator to a destination validator. title: >- QueuedMessage is a message that can change the validator set and is delayed to the epoch boundary title: |- QueuedMessageList is a message that contains a list of staking-related messages queued for an epoch babylon.epoching.v1.ValStateUpdate: type: object properties: state: type: string enum: - CREATED - BONDED - UNBONDING - UNBONDED - REMOVED default: CREATED description: |- - CREATED: CREATED is when the validator/delegation has been created - BONDED: CREATED is when the validator/delegation has become bonded - UNBONDING: CREATED is when the validator/delegation has become unbonding - UNBONDED: CREATED is when the validator/delegation has become unbonded - REMOVED: CREATED is when the validator/delegation has been removed title: BondState is the bond state of a validator or delegation block_height: type: string format: uint64 block_time: type: string format: date-time title: ValStateUpdate is a messages that records a state update of a validator babylon.epoching.v1.Validator: type: object properties: addr: type: string format: byte title: addr is the validator's address (in sdk.ValAddress) power: type: string format: int64 title: power is the validator's voting power title: Validator is a message that denotes a validator babylon.epoching.v1.ValidatorLifecycle: type: object properties: val_addr: type: string val_life: type: array items: type: object properties: state: type: string enum: - CREATED - BONDED - UNBONDING - UNBONDED - REMOVED default: CREATED description: >- - CREATED: CREATED is when the validator/delegation has been created - BONDED: CREATED is when the validator/delegation has become bonded - UNBONDING: CREATED is when the validator/delegation has become unbonding - UNBONDED: CREATED is when the validator/delegation has become unbonded - REMOVED: CREATED is when the validator/delegation has been removed title: BondState is the bond state of a validator or delegation block_height: type: string format: uint64 block_time: type: string format: date-time title: >- ValStateUpdate is a messages that records a state update of a validator title: |- ValidatorLifecycle is a message that records records the lifecycle of a validator cosmos.base.v1beta1.Coin: type: object properties: denom: type: string amount: type: string description: |- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. cosmos.staking.v1beta1.CommissionRates: type: object properties: rate: type: string description: rate is the commission rate charged to delegators, as a fraction. max_rate: type: string description: >- max_rate defines the maximum commission rate which validator can ever charge, as a fraction. max_change_rate: type: string description: >- max_change_rate defines the maximum daily increase of the validator commission, as a fraction. description: >- CommissionRates defines the initial commission rates to be used for creating a validator. cosmos.staking.v1beta1.Description: type: object properties: moniker: type: string description: moniker defines a human-readable name for the validator. identity: type: string description: >- identity defines an optional identity signature (ex. UPort or Keybase). website: type: string description: website defines an optional website link. security_contact: type: string description: security_contact defines an optional email for security contact. details: type: string description: details define other optional details. description: Description defines a validator description. cosmos.staking.v1beta1.MsgBeginRedelegate: type: object properties: delegator_address: type: string validator_src_address: type: string validator_dst_address: type: string amount: type: object properties: denom: type: string amount: type: string description: |- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: |- MsgBeginRedelegate defines a SDK message for performing a redelegation of coins from a delegator and source validator to a destination validator. cosmos.staking.v1beta1.MsgCreateValidator: type: object properties: description: type: object properties: moniker: type: string description: moniker defines a human-readable name for the validator. identity: type: string description: >- identity defines an optional identity signature (ex. UPort or Keybase). website: type: string description: website defines an optional website link. security_contact: type: string description: security_contact defines an optional email for security contact. details: type: string description: details define other optional details. description: Description defines a validator description. commission: type: object properties: rate: type: string description: rate is the commission rate charged to delegators, as a fraction. max_rate: type: string description: >- max_rate defines the maximum commission rate which validator can ever charge, as a fraction. max_change_rate: type: string description: >- max_change_rate defines the maximum daily increase of the validator commission, as a fraction. description: >- CommissionRates defines the initial commission rates to be used for creating a validator. min_self_delegation: type: string delegator_address: type: string validator_address: type: string pubkey: type: object properties: type_url: type: string description: >- A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. value: type: string format: byte description: >- Must be a valid serialized protocol buffer of the above specified type. description: >- `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } value: type: object properties: denom: type: string amount: type: string description: |- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: MsgCreateValidator defines a SDK message for creating a new validator. cosmos.staking.v1beta1.MsgDelegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: |- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: |- MsgDelegate defines a SDK message for performing a delegation of coins from a delegator to a validator. cosmos.staking.v1beta1.MsgUndelegate: type: object properties: delegator_address: type: string validator_address: type: string amount: type: object properties: denom: type: string amount: type: string description: |- Coin defines a token with a denomination and an amount. NOTE: The amount field is an Int which implements the custom method signatures required by gogoproto. description: |- MsgUndelegate defines a SDK message for performing an undelegation from a delegate and a validator. tendermint.types.BlockID: type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader title: BlockID tendermint.types.Header: type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. tendermint.types.PartSetHeader: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader tendermint.version.Consensus: type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. babylon.checkpointing.v1.CheckpointStateUpdate: type: object properties: state: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: state defines the event of a state transition towards this state block_height: type: string format: uint64 title: >- block_height is the height of the Babylon block that triggers the state update block_time: type: string format: date-time title: >- block_time is the timestamp in the Babylon block that triggers the state update description: CheckpointStateUpdate defines a state transition on the checkpoint. babylon.checkpointing.v1.CheckpointStatus: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. babylon.checkpointing.v1.QueryBlsPublicKeyListResponse: type: object properties: validator_with_bls_keys: type: array items: type: object properties: validator_address: type: string bls_pub_key: type: string format: byte voting_power: type: string format: uint64 title: >- ValidatorWithBlsKey couples validator address, voting power, and its bls public key pagination: description: pagination defines the pagination in the response. type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- QueryBlsPublicKeyListResponse is the response type for the Query/BlsPublicKeys RPC method. babylon.checkpointing.v1.QueryEpochStatusResponse: type: object properties: status: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. description: |- QueryEpochStatusResponse is the response type for the Query/EpochStatus RPC method. babylon.checkpointing.v1.QueryLastCheckpointWithStatusResponse: type: object properties: raw_checkpoint: type: object properties: epoch_num: type: string format: uint64 title: epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs title: RawCheckpoint wraps the BLS multi sig with meta data description: |- QueryLastCheckpointWithStatusResponse is the response type for the Query/LastCheckpointWithStatus RPC method. babylon.checkpointing.v1.QueryRawCheckpointListResponse: type: object properties: raw_checkpoints: type: array items: type: object properties: ckpt: type: object properties: epoch_num: type: string format: uint64 title: epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs title: RawCheckpoint wraps the BLS multi sig with meta data status: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: status defines the status of the checkpoint bls_aggr_pk: type: string format: byte title: bls_aggr_pk defines the aggregated BLS public key power_sum: type: string format: uint64 title: >- power_sum defines the accumulated voting power for the checkpoint lifecycle: type: array items: type: object properties: state: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: >- state defines the event of a state transition towards this state block_height: type: string format: uint64 title: >- block_height is the height of the Babylon block that triggers the state update block_time: type: string format: date-time title: >- block_time is the timestamp in the Babylon block that triggers the state update description: >- CheckpointStateUpdate defines a state transition on the checkpoint. description: >- lifecycle defines the lifecycle of this checkpoint, i.e., each state transition and the time (in both timestamp and block height) of this transition. description: RawCheckpointWithMeta wraps the raw checkpoint with meta data. title: the order is going from the newest to oldest based on the epoch number pagination: description: pagination defines the pagination in the response. type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- QueryRawCheckpointListResponse is the response type for the Query/RawCheckpoints RPC method. babylon.checkpointing.v1.QueryRawCheckpointResponse: type: object properties: raw_checkpoint: type: object properties: ckpt: type: object properties: epoch_num: type: string format: uint64 title: epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs title: RawCheckpoint wraps the BLS multi sig with meta data status: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: status defines the status of the checkpoint bls_aggr_pk: type: string format: byte title: bls_aggr_pk defines the aggregated BLS public key power_sum: type: string format: uint64 title: power_sum defines the accumulated voting power for the checkpoint lifecycle: type: array items: type: object properties: state: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: >- state defines the event of a state transition towards this state block_height: type: string format: uint64 title: >- block_height is the height of the Babylon block that triggers the state update block_time: type: string format: date-time title: >- block_time is the timestamp in the Babylon block that triggers the state update description: >- CheckpointStateUpdate defines a state transition on the checkpoint. description: >- lifecycle defines the lifecycle of this checkpoint, i.e., each state transition and the time (in both timestamp and block height) of this transition. description: RawCheckpointWithMeta wraps the raw checkpoint with meta data. description: >- QueryRawCheckpointResponse is the response type for the Query/RawCheckpoint RPC method. babylon.checkpointing.v1.QueryRawCheckpointsResponse: type: object properties: raw_checkpoints: type: array items: type: object properties: ckpt: type: object properties: epoch_num: type: string format: uint64 title: epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs title: RawCheckpoint wraps the BLS multi sig with meta data status: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: status defines the status of the checkpoint bls_aggr_pk: type: string format: byte title: bls_aggr_pk defines the aggregated BLS public key power_sum: type: string format: uint64 title: >- power_sum defines the accumulated voting power for the checkpoint lifecycle: type: array items: type: object properties: state: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: >- state defines the event of a state transition towards this state block_height: type: string format: uint64 title: >- block_height is the height of the Babylon block that triggers the state update block_time: type: string format: date-time title: >- block_time is the timestamp in the Babylon block that triggers the state update description: >- CheckpointStateUpdate defines a state transition on the checkpoint. description: >- lifecycle defines the lifecycle of this checkpoint, i.e., each state transition and the time (in both timestamp and block height) of this transition. description: RawCheckpointWithMeta wraps the raw checkpoint with meta data. title: the order is going from the newest to oldest based on the epoch number pagination: description: pagination defines the pagination in the response. type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: >- QueryRawCheckpointsResponse is the response type for the Query/RawCheckpoints RPC method. babylon.checkpointing.v1.QueryRecentEpochStatusCountResponse: type: object properties: tip_epoch: type: string format: uint64 epoch_count: type: string format: uint64 status_count: type: object additionalProperties: type: string format: uint64 description: |- QueryRecentEpochStatusCountResponse is the response type for the Query/EpochStatusCount RPC method. babylon.checkpointing.v1.RawCheckpoint: type: object properties: epoch_num: type: string format: uint64 title: epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs title: RawCheckpoint wraps the BLS multi sig with meta data babylon.checkpointing.v1.RawCheckpointWithMeta: type: object properties: ckpt: type: object properties: epoch_num: type: string format: uint64 title: epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs title: RawCheckpoint wraps the BLS multi sig with meta data status: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: status defines the status of the checkpoint bls_aggr_pk: type: string format: byte title: bls_aggr_pk defines the aggregated BLS public key power_sum: type: string format: uint64 title: power_sum defines the accumulated voting power for the checkpoint lifecycle: type: array items: type: object properties: state: type: string enum: - CKPT_STATUS_ACCUMULATING - CKPT_STATUS_SEALED - CKPT_STATUS_SUBMITTED - CKPT_STATUS_CONFIRMED - CKPT_STATUS_FINALIZED default: CKPT_STATUS_ACCUMULATING description: |- CheckpointStatus is the status of a checkpoint. - CKPT_STATUS_ACCUMULATING: ACCUMULATING defines a checkpoint that is awaiting for BLS signatures. - CKPT_STATUS_SEALED: SEALED defines a checkpoint that has accumulated sufficient BLS signatures. - CKPT_STATUS_SUBMITTED: SUBMITTED defines a checkpoint that is included on BTC. - CKPT_STATUS_CONFIRMED: CONFIRMED defines a checkpoint that is k-deep on BTC. - CKPT_STATUS_FINALIZED: FINALIZED defines a checkpoint that is w-deep on BTC. title: state defines the event of a state transition towards this state block_height: type: string format: uint64 title: >- block_height is the height of the Babylon block that triggers the state update block_time: type: string format: date-time title: >- block_time is the timestamp in the Babylon block that triggers the state update description: CheckpointStateUpdate defines a state transition on the checkpoint. description: |- lifecycle defines the lifecycle of this checkpoint, i.e., each state transition and the time (in both timestamp and block height) of this transition. description: RawCheckpointWithMeta wraps the raw checkpoint with meta data. babylon.checkpointing.v1.ValidatorWithBlsKey: type: object properties: validator_address: type: string bls_pub_key: type: string format: byte voting_power: type: string format: uint64 title: |- ValidatorWithBlsKey couples validator address, voting power, and its bls public key babylon.zoneconcierge.v1.ChainInfo: type: object properties: chain_id: type: string title: chain_id is the ID of the chain latest_header: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: |- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header latest_forks: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: >- blocks is the list of non-canonical indexed headers at the same height description: >- Forks is a list of non-canonical `IndexedHeader`s at the same height. For example, assuming the following blockchain ``` A <- B <- C <- D <- E \ -- D1 \ -- D2 ``` Then the fork will be {[D1, D2]} where each item is in struct `IndexedBlock`. Note that each `IndexedHeader` in the fork should have a valid quorum certificate. Such forks exist since Babylon considers CZs might have dishonest majority. Also note that the IBC-Go implementation will only consider the first header in a fork valid, since the subsequent headers cannot be verified without knowing the validator set in the previous header. title: >- latest_forks is the latest forks, formed as a series of IndexedHeader (from low to high) timestamped_headers_count: type: string format: uint64 title: |- timestamped_headers_count is the number of timestamped headers in CZ's canonical chain title: ChainInfo is the information of a CZ babylon.zoneconcierge.v1.FinalizedChainInfo: type: object properties: chain_id: type: string title: chain_id is the ID of the chain finalized_chain_info: type: object properties: chain_id: type: string title: chain_id is the ID of the chain latest_header: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header latest_forks: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: >- blocks is the list of non-canonical indexed headers at the same height description: >- Forks is a list of non-canonical `IndexedHeader`s at the same height. For example, assuming the following blockchain ``` A <- B <- C <- D <- E \ -- D1 \ -- D2 ``` Then the fork will be {[D1, D2]} where each item is in struct `IndexedBlock`. Note that each `IndexedHeader` in the fork should have a valid quorum certificate. Such forks exist since Babylon considers CZs might have dishonest majority. Also note that the IBC-Go implementation will only consider the first header in a fork valid, since the subsequent headers cannot be verified without knowing the validator set in the previous header. title: >- latest_forks is the latest forks, formed as a series of IndexedHeader (from low to high) timestamped_headers_count: type: string format: uint64 title: >- timestamped_headers_count is the number of timestamped headers in CZ's canonical chain title: ChainInfo is the information of a CZ epoch_info: title: epoch_info is the metadata of the last BTC-finalised epoch type: object properties: epoch_number: type: string format: uint64 current_epoch_interval: type: string format: uint64 first_block_height: type: string format: uint64 last_block_header: description: >- last_block_header is the header of the last block in this epoch. Babylon needs to remember the last header of each epoch to complete unbonding validators/delegations when a previous epoch's checkpoint is finalised. The last_block_header field is nil in the epoch's beginning, and is set upon the end of this epoch. type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte app_hash_root: type: string format: byte title: |- app_hash_root is the Merkle root of all AppHashs in this epoch It will be used for proving a block is in an epoch sealer_header: title: >- sealer_header is the 2nd header of the next epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. raw_checkpoint: title: raw_checkpoint is the raw checkpoint of this epoch type: object properties: epoch_num: type: string format: uint64 title: epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs btc_submission_key: title: |- btc_submission_key is position of two BTC txs that include the raw checkpoint of this epoch type: object properties: key: type: array items: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block proof: title: proof is the proof that the chain info is finalized type: object properties: proof_tx_in_block: title: >- proof_tx_in_block is the proof that tx that carries the header is included in a certain Babylon block type: object properties: root_hash: type: string format: byte data: type: string format: byte proof: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte description: >- TxProof represents a Merkle proof of the presence of a transaction in the Merkle tree. proof_header_in_epoch: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte title: >- proof_header_in_epoch is the proof that the Babylon header is in a certain epoch proof_epoch_sealed: title: proof_epoch_sealed is the proof that the epoch is sealed type: object properties: validator_set: type: array items: type: object properties: validator_address: type: string bls_pub_key: type: string format: byte voting_power: type: string format: uint64 title: >- ValidatorWithBlsKey couples validator address, voting power, and its bls public key title: >- validator_set is the validator set of the sealed epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header proof_epoch_info: title: >- proof_epoch_info is the Merkle proof that the epoch's metadata is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: >- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash proof_epoch_val_set: title: >- proof_epoch_info is the Merkle proof that the epoch's validator set is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: >- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash proof_epoch_submitted: type: array items: type: object properties: key: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block description: >- key is the position (txIdx, blockHash) of this tx on BTC blockchain Although it is already a part of SubmissionKey, we store it here again to make TransactionInfo self-contained. For example, storing the key allows TransactionInfo to not relay on the fact that TransactionInfo will be ordered in the same order as TransactionKeys in SubmissionKey. transaction: type: string format: byte title: transaction is the full transaction in bytes proof: type: string format: byte title: >- proof is the Merkle proof that this tx is included in the position in `key` TODO: maybe it could use here better format as we already processed and valideated the proof? title: >- TransactionInfo is the info of a tx that contains Babylon checkpoint, including - the position of the tx on BTC blockchain - the full tx content - the Merkle proof that this tx is on the above position title: >- proof_epoch_submitted is the proof that the epoch's checkpoint is included in BTC ledger It is the two TransactionInfo in the best (i.e., earliest) checkpoint submission title: FinalizedChainInfo is the information of a CZ that is BTC-finalised babylon.zoneconcierge.v1.Forks: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: |- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: blocks is the list of non-canonical indexed headers at the same height description: >- Forks is a list of non-canonical `IndexedHeader`s at the same height. For example, assuming the following blockchain ``` A <- B <- C <- D <- E \ -- D1 \ -- D2 ``` Then the fork will be {[D1, D2]} where each item is in struct `IndexedBlock`. Note that each `IndexedHeader` in the fork should have a valid quorum certificate. Such forks exist since Babylon considers CZs might have dishonest majority. Also note that the IBC-Go implementation will only consider the first header in a fork valid, since the subsequent headers cannot be verified without knowing the validator set in the previous header. babylon.zoneconcierge.v1.IndexedHeader: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: |- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header babylon.zoneconcierge.v1.Params: type: object properties: ibc_packet_timeout_seconds: type: integer format: int64 title: >- ibc_packet_timeout_seconds is the time period after which an unrelayed IBC packet becomes timeout, measured in seconds description: Params defines the parameters for the module. babylon.zoneconcierge.v1.ProofEpochSealed: type: object properties: validator_set: type: array items: type: object properties: validator_address: type: string bls_pub_key: type: string format: byte voting_power: type: string format: uint64 title: >- ValidatorWithBlsKey couples validator address, voting power, and its bls public key title: >- validator_set is the validator set of the sealed epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header proof_epoch_info: title: >- proof_epoch_info is the Merkle proof that the epoch's metadata is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: |- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash proof_epoch_val_set: title: |- proof_epoch_info is the Merkle proof that the epoch's validator set is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: |- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash title: >- ProofEpochSealed is the proof that an epoch is sealed by the sealer header, i.e., the 2nd header of the next epoch With the access of metadata - Metadata of this epoch, which includes the sealer header - Raw checkpoint of this epoch The verifier can perform the following verification rules: - The raw checkpoint's `last_commit_hash` is same as in the sealer header - More than 1/3 (in voting power) validators in the validator set of this epoch have signed `last_commit_hash` of the sealer header - The epoch medatata is committed to the `app_hash` of the sealer header - The validator set is committed to the `app_hash` of the sealer header babylon.zoneconcierge.v1.ProofFinalizedChainInfo: type: object properties: proof_tx_in_block: title: >- proof_tx_in_block is the proof that tx that carries the header is included in a certain Babylon block type: object properties: root_hash: type: string format: byte data: type: string format: byte proof: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte description: >- TxProof represents a Merkle proof of the presence of a transaction in the Merkle tree. proof_header_in_epoch: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte title: >- proof_header_in_epoch is the proof that the Babylon header is in a certain epoch proof_epoch_sealed: title: proof_epoch_sealed is the proof that the epoch is sealed type: object properties: validator_set: type: array items: type: object properties: validator_address: type: string bls_pub_key: type: string format: byte voting_power: type: string format: uint64 title: >- ValidatorWithBlsKey couples validator address, voting power, and its bls public key title: >- validator_set is the validator set of the sealed epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header proof_epoch_info: title: >- proof_epoch_info is the Merkle proof that the epoch's metadata is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: >- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash proof_epoch_val_set: title: >- proof_epoch_info is the Merkle proof that the epoch's validator set is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: >- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash proof_epoch_submitted: type: array items: type: object properties: key: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block description: >- key is the position (txIdx, blockHash) of this tx on BTC blockchain Although it is already a part of SubmissionKey, we store it here again to make TransactionInfo self-contained. For example, storing the key allows TransactionInfo to not relay on the fact that TransactionInfo will be ordered in the same order as TransactionKeys in SubmissionKey. transaction: type: string format: byte title: transaction is the full transaction in bytes proof: type: string format: byte title: >- proof is the Merkle proof that this tx is included in the position in `key` TODO: maybe it could use here better format as we already processed and valideated the proof? title: >- TransactionInfo is the info of a tx that contains Babylon checkpoint, including - the position of the tx on BTC blockchain - the full tx content - the Merkle proof that this tx is on the above position title: >- proof_epoch_submitted is the proof that the epoch's checkpoint is included in BTC ledger It is the two TransactionInfo in the best (i.e., earliest) checkpoint submission title: |- ProofFinalizedChainInfo is a set of proofs that attest a chain info is BTC-finalised babylon.zoneconcierge.v1.QueryChainListResponse: type: object properties: chain_ids: type: array items: type: string title: chain_ids are IDs of the chains in ascending alphabetical order pagination: title: pagination defines the pagination in the response type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } title: QueryChainListResponse is response type for the Query/ChainList RPC method babylon.zoneconcierge.v1.QueryChainsInfoResponse: type: object properties: chains_info: type: array items: type: object properties: chain_id: type: string title: chain_id is the ID of the chain latest_header: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header latest_forks: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: >- blocks is the list of non-canonical indexed headers at the same height description: >- Forks is a list of non-canonical `IndexedHeader`s at the same height. For example, assuming the following blockchain ``` A <- B <- C <- D <- E \ -- D1 \ -- D2 ``` Then the fork will be {[D1, D2]} where each item is in struct `IndexedBlock`. Note that each `IndexedHeader` in the fork should have a valid quorum certificate. Such forks exist since Babylon considers CZs might have dishonest majority. Also note that the IBC-Go implementation will only consider the first header in a fork valid, since the subsequent headers cannot be verified without knowing the validator set in the previous header. title: >- latest_forks is the latest forks, formed as a series of IndexedHeader (from low to high) timestamped_headers_count: type: string format: uint64 title: >- timestamped_headers_count is the number of timestamped headers in CZ's canonical chain title: ChainInfo is the information of a CZ description: >- QueryChainsInfoResponse is response type for the Query/ChainsInfo RPC method. babylon.zoneconcierge.v1.QueryEpochChainsInfoResponse: type: object properties: chains_info: type: array items: type: object properties: chain_id: type: string title: chain_id is the ID of the chain latest_header: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header latest_forks: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: >- blocks is the list of non-canonical indexed headers at the same height description: >- Forks is a list of non-canonical `IndexedHeader`s at the same height. For example, assuming the following blockchain ``` A <- B <- C <- D <- E \ -- D1 \ -- D2 ``` Then the fork will be {[D1, D2]} where each item is in struct `IndexedBlock`. Note that each `IndexedHeader` in the fork should have a valid quorum certificate. Such forks exist since Babylon considers CZs might have dishonest majority. Also note that the IBC-Go implementation will only consider the first header in a fork valid, since the subsequent headers cannot be verified without knowing the validator set in the previous header. title: >- latest_forks is the latest forks, formed as a series of IndexedHeader (from low to high) timestamped_headers_count: type: string format: uint64 title: >- timestamped_headers_count is the number of timestamped headers in CZ's canonical chain title: ChainInfo is the information of a CZ title: chain_info is the info of the CZ description: >- QueryEpochChainsInfoResponse is response type for the Query/EpochChainsInfo RPC method. babylon.zoneconcierge.v1.QueryFinalizedChainInfoUntilHeightResponse: type: object properties: finalized_chain_info: type: object properties: chain_id: type: string title: chain_id is the ID of the chain latest_header: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header latest_forks: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: >- blocks is the list of non-canonical indexed headers at the same height description: >- Forks is a list of non-canonical `IndexedHeader`s at the same height. For example, assuming the following blockchain ``` A <- B <- C <- D <- E \ -- D1 \ -- D2 ``` Then the fork will be {[D1, D2]} where each item is in struct `IndexedBlock`. Note that each `IndexedHeader` in the fork should have a valid quorum certificate. Such forks exist since Babylon considers CZs might have dishonest majority. Also note that the IBC-Go implementation will only consider the first header in a fork valid, since the subsequent headers cannot be verified without knowing the validator set in the previous header. title: >- latest_forks is the latest forks, formed as a series of IndexedHeader (from low to high) timestamped_headers_count: type: string format: uint64 title: >- timestamped_headers_count is the number of timestamped headers in CZ's canonical chain title: ChainInfo is the information of a CZ epoch_info: title: epoch_info is the metadata of the last BTC-finalised epoch type: object properties: epoch_number: type: string format: uint64 current_epoch_interval: type: string format: uint64 first_block_height: type: string format: uint64 last_block_header: description: >- last_block_header is the header of the last block in this epoch. Babylon needs to remember the last header of each epoch to complete unbonding validators/delegations when a previous epoch's checkpoint is finalised. The last_block_header field is nil in the epoch's beginning, and is set upon the end of this epoch. type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte app_hash_root: type: string format: byte title: |- app_hash_root is the Merkle root of all AppHashs in this epoch It will be used for proving a block is in an epoch sealer_header: title: >- sealer_header is the 2nd header of the next epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. raw_checkpoint: title: raw_checkpoint is the raw checkpoint of this epoch type: object properties: epoch_num: type: string format: uint64 title: epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs btc_submission_key: title: |- btc_submission_key is position of two BTC txs that include the raw checkpoint of this epoch type: object properties: key: type: array items: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block proof: title: proof is the proof that the chain info is finalized type: object properties: proof_tx_in_block: title: >- proof_tx_in_block is the proof that tx that carries the header is included in a certain Babylon block type: object properties: root_hash: type: string format: byte data: type: string format: byte proof: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte description: >- TxProof represents a Merkle proof of the presence of a transaction in the Merkle tree. proof_header_in_epoch: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte title: >- proof_header_in_epoch is the proof that the Babylon header is in a certain epoch proof_epoch_sealed: title: proof_epoch_sealed is the proof that the epoch is sealed type: object properties: validator_set: type: array items: type: object properties: validator_address: type: string bls_pub_key: type: string format: byte voting_power: type: string format: uint64 title: >- ValidatorWithBlsKey couples validator address, voting power, and its bls public key title: >- validator_set is the validator set of the sealed epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header proof_epoch_info: title: >- proof_epoch_info is the Merkle proof that the epoch's metadata is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: >- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash proof_epoch_val_set: title: >- proof_epoch_info is the Merkle proof that the epoch's validator set is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: >- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash proof_epoch_submitted: type: array items: type: object properties: key: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block description: >- key is the position (txIdx, blockHash) of this tx on BTC blockchain Although it is already a part of SubmissionKey, we store it here again to make TransactionInfo self-contained. For example, storing the key allows TransactionInfo to not relay on the fact that TransactionInfo will be ordered in the same order as TransactionKeys in SubmissionKey. transaction: type: string format: byte title: transaction is the full transaction in bytes proof: type: string format: byte title: >- proof is the Merkle proof that this tx is included in the position in `key` TODO: maybe it could use here better format as we already processed and valideated the proof? title: >- TransactionInfo is the info of a tx that contains Babylon checkpoint, including - the position of the tx on BTC blockchain - the full tx content - the Merkle proof that this tx is on the above position title: >- proof_epoch_submitted is the proof that the epoch's checkpoint is included in BTC ledger It is the two TransactionInfo in the best (i.e., earliest) checkpoint submission description: |- QueryFinalizedChainInfoUntilHeightResponse is response type for the Query/FinalizedChainInfoUntilHeight RPC method. babylon.zoneconcierge.v1.QueryFinalizedChainsInfoResponse: type: object properties: finalized_chains_info: type: array items: type: object properties: chain_id: type: string title: chain_id is the ID of the chain finalized_chain_info: type: object properties: chain_id: type: string title: chain_id is the ID of the chain latest_header: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header latest_forks: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: >- epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: >- blocks is the list of non-canonical indexed headers at the same height description: >- Forks is a list of non-canonical `IndexedHeader`s at the same height. For example, assuming the following blockchain ``` A <- B <- C <- D <- E \ -- D1 \ -- D2 ``` Then the fork will be {[D1, D2]} where each item is in struct `IndexedBlock`. Note that each `IndexedHeader` in the fork should have a valid quorum certificate. Such forks exist since Babylon considers CZs might have dishonest majority. Also note that the IBC-Go implementation will only consider the first header in a fork valid, since the subsequent headers cannot be verified without knowing the validator set in the previous header. title: >- latest_forks is the latest forks, formed as a series of IndexedHeader (from low to high) timestamped_headers_count: type: string format: uint64 title: >- timestamped_headers_count is the number of timestamped headers in CZ's canonical chain title: ChainInfo is the information of a CZ epoch_info: title: epoch_info is the metadata of the last BTC-finalised epoch type: object properties: epoch_number: type: string format: uint64 current_epoch_interval: type: string format: uint64 first_block_height: type: string format: uint64 last_block_header: description: >- last_block_header is the header of the last block in this epoch. Babylon needs to remember the last header of each epoch to complete unbonding validators/delegations when a previous epoch's checkpoint is finalised. The last_block_header field is nil in the epoch's beginning, and is set upon the end of this epoch. type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte app_hash_root: type: string format: byte title: >- app_hash_root is the Merkle root of all AppHashs in this epoch It will be used for proving a block is in an epoch sealer_header: title: >- sealer_header is the 2nd header of the next epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. raw_checkpoint: title: raw_checkpoint is the raw checkpoint of this epoch type: object properties: epoch_num: type: string format: uint64 title: epoch_num defines the epoch number the raw checkpoint is for last_commit_hash: type: string format: byte title: >- last_commit_hash defines the 'LastCommitHash' that individual BLS sigs are signed on bitmap: type: string format: byte title: >- bitmap defines the bitmap that indicates the signers of the BLS multi sig bls_multi_sig: type: string format: byte title: >- bls_multi_sig defines the multi sig that is aggregated from individual BLS sigs btc_submission_key: title: >- btc_submission_key is position of two BTC txs that include the raw checkpoint of this epoch type: object properties: key: type: array items: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block proof: title: proof is the proof that the chain info is finalized type: object properties: proof_tx_in_block: title: >- proof_tx_in_block is the proof that tx that carries the header is included in a certain Babylon block type: object properties: root_hash: type: string format: byte data: type: string format: byte proof: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte description: >- TxProof represents a Merkle proof of the presence of a transaction in the Merkle tree. proof_header_in_epoch: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte title: >- proof_header_in_epoch is the proof that the Babylon header is in a certain epoch proof_epoch_sealed: title: proof_epoch_sealed is the proof that the epoch is sealed type: object properties: validator_set: type: array items: type: object properties: validator_address: type: string bls_pub_key: type: string format: byte voting_power: type: string format: uint64 title: >- ValidatorWithBlsKey couples validator address, voting power, and its bls public key title: >- validator_set is the validator set of the sealed epoch This validator set has generated a BLS multisig on `last_commit_hash` of the sealer header proof_epoch_info: title: >- proof_epoch_info is the Merkle proof that the epoch's metadata is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: >- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash proof_epoch_val_set: title: >- proof_epoch_info is the Merkle proof that the epoch's validator set is committed to `app_hash` of the sealer header type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: >- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash proof_epoch_submitted: type: array items: type: object properties: key: type: object properties: index: type: integer format: int64 hash: type: string format: byte title: >- Each provided OP_RETURN transaction can be idendtified by hash of block in which transaction was included and transaction index in the block description: >- key is the position (txIdx, blockHash) of this tx on BTC blockchain Although it is already a part of SubmissionKey, we store it here again to make TransactionInfo self-contained. For example, storing the key allows TransactionInfo to not relay on the fact that TransactionInfo will be ordered in the same order as TransactionKeys in SubmissionKey. transaction: type: string format: byte title: transaction is the full transaction in bytes proof: type: string format: byte title: >- proof is the Merkle proof that this tx is included in the position in `key` TODO: maybe it could use here better format as we already processed and valideated the proof? title: >- TransactionInfo is the info of a tx that contains Babylon checkpoint, including - the position of the tx on BTC blockchain - the full tx content - the Merkle proof that this tx is on the above position title: >- proof_epoch_submitted is the proof that the epoch's checkpoint is included in BTC ledger It is the two TransactionInfo in the best (i.e., earliest) checkpoint submission title: FinalizedChainInfo is the information of a CZ that is BTC-finalised description: |- QueryFinalizedChainsInfoResponse is response type for the Query/FinalizedChainsInfo RPC method. babylon.zoneconcierge.v1.QueryHeaderResponse: type: object properties: header: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: |- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header fork_headers: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: >- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: >- blocks is the list of non-canonical indexed headers at the same height description: >- Forks is a list of non-canonical `IndexedHeader`s at the same height. For example, assuming the following blockchain ``` A <- B <- C <- D <- E \ -- D1 \ -- D2 ``` Then the fork will be {[D1, D2]} where each item is in struct `IndexedBlock`. Note that each `IndexedHeader` in the fork should have a valid quorum certificate. Such forks exist since Babylon considers CZs might have dishonest majority. Also note that the IBC-Go implementation will only consider the first header in a fork valid, since the subsequent headers cannot be verified without knowing the validator set in the previous header. description: QueryHeaderResponse is response type for the Query/Header RPC method. babylon.zoneconcierge.v1.QueryListEpochHeadersResponse: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: |- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: headers is the list of headers description: >- QueryListEpochHeadersResponse is response type for the Query/ListEpochHeaders RPC method. babylon.zoneconcierge.v1.QueryListHeadersResponse: type: object properties: headers: type: array items: type: object properties: chain_id: type: string title: chain_id is the unique ID of the chain hash: type: string format: byte title: hash is the hash of this header height: type: string format: uint64 title: >- height is the height of this header on CZ ledger (hash, height) jointly provides the position of the header on CZ ledger time: type: string format: date-time title: |- time is the timestamp of this header on CZ ledger it is needed for CZ to unbond all mature validators/delegations before this timestamp when this header is BTC-finalised babylon_header: title: >- babylon_header is the header of the babylon block that includes this CZ header type: object properties: version: title: basic block info type: object properties: block: type: string format: uint64 app: type: string format: uint64 description: >- Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. chain_id: type: string height: type: string format: int64 time: type: string format: date-time last_block_id: title: prev block info type: object properties: hash: type: string format: byte part_set_header: type: object properties: total: type: integer format: int64 hash: type: string format: byte title: PartsetHeader last_commit_hash: type: string format: byte title: hashes of block data data_hash: type: string format: byte validators_hash: type: string format: byte title: hashes from the app output from the prev block next_validators_hash: type: string format: byte consensus_hash: type: string format: byte app_hash: type: string format: byte last_results_hash: type: string format: byte evidence_hash: type: string format: byte title: consensus info proposer_address: type: string format: byte description: Header defines the structure of a block header. babylon_epoch: type: string format: uint64 title: epoch is the epoch number of this header on Babylon ledger babylon_tx_hash: type: string format: byte title: >- babylon_tx_hash is the hash of the tx that includes this header (babylon_block_height, babylon_tx_hash) jointly provides the position of the header on Babylon ledger title: IndexedHeader is the metadata of a CZ header title: headers is the list of headers pagination: title: pagination defines the pagination in the response type: object properties: next_key: type: string format: byte description: |- next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. total: type: string format: uint64 title: >- total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise description: |- PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } description: |- QueryListHeadersResponse is response type for the Query/ListHeaders RPC method. babylon.zoneconcierge.v1.QueryParamsResponse: type: object properties: params: description: params holds all the parameters of this module. type: object properties: ibc_packet_timeout_seconds: type: integer format: int64 title: >- ibc_packet_timeout_seconds is the time period after which an unrelayed IBC packet becomes timeout, measured in seconds description: QueryParamsResponse is the response type for the Query/Params RPC method. tendermint.crypto.Proof: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte tendermint.crypto.ProofOp: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: |- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash tendermint.crypto.ProofOps: type: object properties: ops: type: array items: type: object properties: type: type: string key: type: string format: byte data: type: string format: byte title: |- ProofOp defines an operation used for calculating Merkle root The data could be arbitrary format, providing nessecary data for example neighbouring node hash title: ProofOps is Merkle proof defined by the list of ProofOps tendermint.types.TxProof: type: object properties: root_hash: type: string format: byte data: type: string format: byte proof: type: object properties: total: type: string format: int64 index: type: string format: int64 leaf_hash: type: string format: byte aunts: type: array items: type: string format: byte description: >- TxProof represents a Merkle proof of the presence of a transaction in the Merkle tree.