The Outpost API was first built to support the Tendermint-base Cosmos Network to discover the underlying trends of this year-old blockchain. As part of building out KysenPool, we realized that there were quite a number of efforts to build out chain explorers and diving into chain analytics, but there was little emphasis on visualizing what the underlying trends really looks like.
There could be a lot of hype in a particular chain but when rubber meets the road, the analysis of the trends of how practical each blockchain is being used will reveal its true value, especially if it reveals growing positive trends over time.
The Outpost API is highly specific in this proof of concept version that traces the following blockchain message types inherent to the Cosmos Network, in order to help trend out the following activities:
- Delegations / ReDelegations / UnDelegations — the amount of token delegations being moved in and out of validators
- Rewards & Commissions — how active the community is in really building automations around maximizing their rewards and pulling their commissions to be maximize utility
- Send Transaction Volume — how many token transfers are happening and at what total volume in each block of time
- Success & Failure Rates — how well the ecosystem is built out, whether via automation scripts, or via dApps are they operating to push transactions through the chain without running out of gas or running haphazard scripts
- Validator Uptime — how secure and lively is the underlying mini-data centers supporting the cryptography behind each block being verified and signed
API URL
First off, the backend API is publicly available and it’s simply https://api.cosmosoutpost.io
NOTE: Ok, now we’ve revealed it! Please be kind to keep your search time range within reasonable limits (e.g. 30 days) to avoid hitting the API too hard and taxing the backend indexing service. It’s not built for public use hence there’s no auto-scaling just yet. This a beta build-out on a shoestring budget! To help support us, there’s a delegation link at the end of this post to help support our cause.
Example
https://api.cosmosoutpost.io/cosmos/txs/delegations/1582618980000/1583914980000/?resolution=1dResolutions
Secondly, note that there’s a concept of resolutions. The API supports data density in the following resolutions:
1m / 5m / 15m / 1h / 4h / 1dMeaning it gives you the ability to manage the data fidelity that you’re interested in within an overarching time window delimited by a “from” and “to” timestamp.
For example, if you set your resolution to “5m” to summarize 5-minute resolution buckets, and your timestamped window happens to be 24 hours apart, then you expect to receive see 288 record sets representing the activities in that 24 hour period.
Request Params
The following are the general parameters used in every endpoint
- from_time_in_millis : time in UTC since epoch, in milliseconds, to start from
- to_time_in_millis : time in UTC since epoch, in milliseconds, to end at
- resolution : (optional) how dense to group them together in, supported values are 1m / 5m / 15m / 1h / 4h / 1d (default is 1m, or 60000ms)
Enjoy!
Delegations
Supported message types: MsgBeginRedelegate, MsgDelegate, MsgUndelegate
Request URI
/cosmos/txs/delegations/:from_time_in_millis/:to_time_in_millis/?resolution=:resolutionResponse Sample
{
"txs": {
"MsgDelegate": {
1567659780000: 5123456, # this is 5.123456 ATOMs
1567659840000: 123450000, # this is 123.45 ATOMs
1567659900000: 12345000 # this is 12.345 ATOMs
},
"MsgUndelegate": {
1567659780000: 5123456, # this is 5.123456 ATOMs
1567659840000: 123450000, # this is 123.45 ATOMs
1567659900000: 12345000 # this is 12.345 ATOMs
},
"MsgBeginRedelegate": {
1567659780000: 5123456, # this is 5.123456 ATOMs
1567659840000: 123450000, # this is 123.45 ATOMs
1567659900000: 12345000 # this is 12.345 ATOMs
}
},
"ts": 1567661881921
}Rewards
Supported message types: MsgWithdrawDelegationReward, MsgWithdrawValidatorCommission
Request URI
/cosmos/txs/rewards/:from_time_in_millis/:to_time_in_millis/?resolution=:resolutionResponse Sample
{
"txs": {
"MsgWithdrawDelegationReward": {
1567659780000: 5123456, # this is 5.123456 ATOMs
1567659840000: 123450000, # this is 123.45 ATOMs
1567659900000: 12345000 # this is 12.345 ATOMs
},
"MsgWithdrawValidatorCommission": {
1567659780000: 5123456, # this is 5.123456 ATOMs
1567659840000: 123450000, # this is 123.45 ATOMs
1567659900000: 12345000 # this is 12.345 ATOMs
}
},
"ts": 1567661881921
}Send / Receive
Supported message types: MsgSend, MsgMultiSend
Request URI format
/cosmos/txs/sends/:from_time_in_millis/:to_time_in_millis/?resolution=:resolutionSample Response
{
"txs": {
"MsgSend": {
1567659780000: 5123456, # this is 5.123456 ATOMs
1567659840000: 123450000, # this is 123.45 ATOMs
1567659900000: 12345000 # this is 12.345 ATOMs
},
"MsgMultiSend": {
1567659780000: 5123456, # this is 5.123456 ATOMs
1567659840000: 123450000, # this is 123.45 ATOMs
1567659900000: 12345000 # this is 12.345 ATOMs
}
},
"ts": 1567661881921
}Success & Failure Rates
This is a side effect of a completed transaction
Request
/cosmos/txs/success/:from_time_in_millis/:to_time_in_millis/?resolution=:resolutionResponse Sample
{
"success": {
1567659780000: 5,
1567659840000: 8,
1567659900000: 9
},
"failure": {
1567659780000: 3,
1567659840000: 1,
1567659900000: 0
},
"ts": 1567661881921
}Now, onto Validator Uptime!
Validator Uptime
We basically check to see whether a validator has submitted pre-commits during this block. If there was none, then it’s considered an outage, or a missed pre-commit, during this block, where the validator was either unreachable, or did not submit a pre-commit in time before the wait interval is up, after gaining the 2/3 consensus. The response will also include the validator address of the“proposer” as a separate element at the root of the response
Request URI
/cosmos/commits/{validator}?blocks={blocks}Request Params
{validator}- “active” — pull all active validators
- validator’s address hex, e.g. 9DF8E338C85E…
{blocks}- number of block height counts, counting back from the most recent block. Defaults to 100
You can optionally look for a single validator’s uptime, or look for all “active” validators. If a validator is down, it will be missing from the active set.
Response Sample
The following is a response payload for the “active” set
{
"validators": {
"<hex address>": {
"commits": {
"1629183": true,
"1629184": true,
:
:
"1629194": true,
"1629195": false,
"1629196": true,
:
:
"1629281": true,
"1629282": true
}
},
"<hex address>": {
"commits": {
"1629183": true,
"1629184": true,
:
:
"1629280": true,
"1629281": false,
"1629282": true
}
}
},
"proposer": {
"1629183": "<hex address>",
"1629184": "<hex address>",
:
:
"1629280": "<hex address>",
"1629281": "<hex address>",
"1629282": "<hex address>"
},
"ts": 1567209863697
}Alternatively if the request is only asking for a “single” validator
{
"validators": {
"<hex address>": {
"commits": [
"157234": true,
"157235": true,
"157236": true,
"157237": true,
"157238": false, # missed block here
"157239": true,
"157240": true,
"157241": true,
"157242": true,
"157243": true,
},
:
:
]
},
"ts": 1566969989274
}NOTE: Unfortunately we have yet to build out a mapping from the validator hex address to the validator name
That’s basically it! Hope this has been useful
Official Channels
Twitter: twitter.com/KysenPool
Medium: medium.com/kysenpool
Telegram: https://t.me/kysenpool
WeChat: KysenPool
LinkedIn: www.linkedin.com/company/kysen-technologies
Delegations welcomed!
🌐 KysenPool.io Cosmos Validator
