GitBook: [#302] No subject

This commit is contained in:
Vahid Zarifpayam 2022-08-29 23:50:05 +00:00 committed by gitbook-bot
parent fdc3a0adea
commit 46abdcf6ca
No known key found for this signature in database
GPG Key ID: 07D2180C7B12D0FF
269 changed files with 7681 additions and 2 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 104 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 102 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 106 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 140 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 98 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 120 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 106 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 98 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 122 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 197 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 126 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 502 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 702 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.1 MiB

BIN
.gitbook/assets/Untitled Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

BIN
.gitbook/assets/Untitled 1 Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 170 KiB

BIN
.gitbook/assets/Untitled 2 Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 13 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 30 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 27 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 170 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 107 KiB

BIN
.gitbook/assets/image.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

BIN
.gitbook/assets/params.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

BIN
.gitbook/assets/pass.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 456 KiB

View File

@ -0,0 +1,184 @@
openapi: 3.0.0
info:
version: 1.0.0
title: "Flipside Rest API"
description: Used to run sql queries on Flipside blockchain data
paths:
/queries:
post:
summary: Queue up the execeution of a sql statement and get a token back which you can use to poll the result
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/ExecParam"
examples:
Simple:
value:
sql: select TX_ID from ethereum.TRANSACTIONS limit 10
With-Parameters:
value:
sql: select {{col}} from ethereum.TRANSACTIONS limit {{amount}}
params:
col: TX_ID
amount: 10
All:
value:
sql: select {{col}} from ethereum.TRANSACTIONS limit {{amount}}
params:
col: TX_ID
amount: 10
cache: true
ttl_minutes: 15
responses:
"200":
description: token used to poll for query results
content:
application/json:
schema:
type: object
required:
- token
- cached
properties:
token:
type: string
description: token used to poll for query result
example: queryRun-3faa00f922cf482ef798b1ec98ee3c16
cached:
type: boolean
description: true if the query result is already cached
"400":
description: error state
content:
application/json:
schema:
$ref: "#/components/schemas/Error"
/queries/{token}:
get:
summary: Poll this endpoint to get the response of your query run
parameters:
- in: path
name: token
required: true
schema:
type: string
description: The token received as a response from POST /queries
example: queryRun-3faa00f922cf482ef798b1ec98ee3c16
- in: query
name: pageNumber
required: false
schema:
type: number
- in: query
name: pageSize
required: false
schema:
type: number
responses:
"200":
description: results of query run and other metadata
content:
application/json:
schema:
$ref: "#/components/schemas/QueryResults"
"400":
description: error state
content:
application/json:
schema:
$ref: "#/components/schemas/Error"
components:
schemas:
ExecParam:
type: object
required:
- sql
properties:
sql:
type: string
description: sql statement to execute
example: select TX_ID from ethereum.TRANSACTIONS limit 10
ttl_minutes:
type: integer
minimum: 1
maximum: 1440
default: 15
description: Amount of time query result will remain in cache.
cache:
type: boolean
default: true
description: If false, will ignore cached results and re-execute.
params:
type: object
description: Key values to replace sql statement with in sql templated parameters.
additionalProperties:
type: string
QueryResults:
type: object
required:
- results
- columnLabels
- status
- startedAt
- endedAt
- columnTypes
properties:
results:
type: array
description: Array of rows. Each row is an array of strings. Each element in a row corresponds to its respective columnLabel.
example: [["1", "2", "3"], ["6", "5", "4"]]
items:
type: array
items:
type: string
columnLabels:
type: array
description: Array of rows. Each row is an array of strings. Each element in a row corresponds to its respective columnLabel.
example: ["day", "avg_deposits", "avg_borrowed"]
items:
type: string
columnTypes:
type: array
items:
type: string
description: Describes data type of each column in a row.
example: ["timestamp", "number", "number"]
status:
type: string
enum: ["finished", "running", "failed"]
description: If running, keep polling until finished.
message:
type: string
description: Indicates an error message
startedAt:
type: string
description: Shows when query started running (ISO 8601)
example: "2022-05-07T00:15:00.000Z"
endedAt:
type: string
description: Shows when query ended running (ISO 8601)
example: "2022-05-07T00:15:01.000Z"
Error:
type: object
required:
- errors
properties:
errors:
type: object
additionalProperties: true
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: X-API-KEY
security:
- ApiKeyAuth: []
servers:
- description: Production server
url: https://node-api.flipsidecrypto.com/

View File

@ -0,0 +1,188 @@
openapi: 3.0.0
info:
version: 1.0.0
title: "Flipside Rest API"
description: Used to run sql queries on Flipside blockchain data
paths:
/queries:
post:
summary: Queue up the execeution of a sql statement and get a token back which you can use to poll the result
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/ExecParam"
examples:
Simple:
value:
sql: select TX_ID from ethereum.TRANSACTIONS limit 10
With-Parameters:
value:
sql: select {{col}} from ethereum.TRANSACTIONS limit {{amount}}
params:
col: TX_ID
amount: 10
All:
value:
sql: select {{col}} from ethereum.TRANSACTIONS limit {{amount}}
params:
col: TX_ID
amount: 10
cache: true
ttl_minutes: 15
responses:
"200":
description: token used to poll for query results
content:
application/json:
schema:
type: object
required:
- token
- cached
properties:
token:
type: string
description: token used to poll for query result
example: queryRun-3faa00f922cf482ef798b1ec98ee3c16
cached:
type: boolean
description: true if the query result is already cached
"400":
description: error state
content:
application/json:
schema:
$ref: "#/components/schemas/Error"
/queries/{token}:
get:
summary: Poll this endpoint to get the response of your query run
parameters:
- in: path
name: token
required: true
schema:
type: string
description: The token received as a response from POST /queries
example: queryRun-3faa00f922cf482ef798b1ec98ee3c16
- in: query
name: limit
required: false
schema:
type: number
- in: query
name: offset
required: false
schema:
type: number
responses:
"200":
description: results of query run and other metadata
content:
application/json:
schema:
$ref: "#/components/schemas/QueryResults"
"400":
description: error state
content:
application/json:
schema:
$ref: "#/components/schemas/Error"
components:
schemas:
ExecParam:
type: object
required:
- sql
properties:
sql:
type: string
description: sql statement to execute
example: select TX_ID from ethereum.TRANSACTIONS limit 10
ttl_minutes:
type: integer
minimum: 1
maximum: 1440
default: 15
description: Amount of time query result will remain in cache.
cache:
type: boolean
default: true
description: If false, will ignore cached results and re-execute.
params:
type: object
description: Key values to replace sql statement with in sql templated parameters.
additionalProperties:
type: string
QueryResults:
type: object
required:
- results
- columnLabels
- status
- startedAt
- endedAt
- columnTypes
properties:
results:
type: array
description: Array of rows. Each row is an array of strings. Each element in a row corresponds to its respective columnLabel.
example: [["1", "2", "3"], ["6", "5", "4"]]
items:
type: array
items:
type: string
columnLabels:
type: array
description: Array of rows. Each row is an array of strings. Each element in a row corresponds to its respective columnLabel.
example: ["day", "avg_deposits", "avg_borrowed"]
items:
type: string
columnTypes:
type: array
items:
type: string
description: Describes data type of each column in a row.
example: ["timestamp", "number", "number"]
status:
type: string
enum: ["finished", "running", "failed"]
description: If running, keep polling until finished.
message:
type: string
description: Indicates an error message
startedAt:
type: string
description: Shows when query started running (ISO 8601)
example: "2022-05-07T00:15:00.000Z"
endedAt:
type: string
description: Shows when query ended running (ISO 8601)
example: "2022-05-07T00:15:01.000Z"
Error:
type: object
required:
- errors
properties:
errors:
type: object
additionalProperties: true
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: X-API-KEY
security:
- ApiKeyAuth: []
servers:
- description: Production server
url: https://node-api.flipsidecrypto.com/
- description: Local Dev
url: http://localhost:3001/
- description: Staging
url: https://node-api.flipside.kitchen/

View File

@ -1,2 +1,21 @@
# gitbook
Flipside's Gitbook docs
---
description: >-
Flipside provides Community Enabled Crypto Analytics, allowing our users to
create and share data insights on the crypto projects they care most about.
---
# What is Flipside?
### Flipside Crypto puts pre-modeled and labeled blockchain data in the hands of communities.
Through dashboard and visualization tools, as well as auto-generated API endpoints, data analysts can easily create queries that answer any question.
### **Community members earn bounties for answering questions with data**
Bounties provide incentive and direction, so crypto projects can quickly source the data insights they need in order to grow.
### **Flipside works directly with leading crypto projects to reward on-demand analytics through structured bounty programs.**
Questions sourced directly from the community provide insight into what communities care about as well as analytics needed to drive ecosystem engagement and growth.\
__

246
SUMMARY.md Normal file
View File

@ -0,0 +1,246 @@
# Table of contents
* [What is Flipside?](README.md)
## Our Data
* [Data Updates](our-data/data-updates.md)
* [Data Model Overview](our-data/data-models/README.md)
* [UDM Events Model](our-data/data-models/events-data-model.md)
* [Address Balance Model](our-data/data-models/balances.md)
* [Labels](our-data/data-models/labels/README.md)
* [Centralized Exchange Label Type](our-data/data-models/labels/cex-label-type.md)
* [Decentralized Exchange Label Type](our-data/data-models/labels/dex-label-type.md)
* [Operator Label Type](our-data/data-models/labels/operator-label-type.md)
* [Chain Admin Label Type](our-data/data-models/labels/chadmin-label-type.md)
* [Decentralized Finance Label Type](our-data/data-models/labels/defi-label-type.md)
* [NonFungible Tokens Label Type](our-data/data-models/labels/nft-label-type.md)
* [Layer Two Label Type](our-data/data-models/labels/layer2-label-type.md)
* [Decentralized Applications Label Type](our-data/data-models/labels/other-label-type.md)
* [Token Label Type](our-data/data-models/labels/token-label-type.md)
* [Flotsam Label Type](our-data/data-models/labels/flotsam-label-type.md)
* [Tags](our-data/data-models/tags.md)
* [Facts and Dimensions](our-data/data-models/facts-and-dimensions.md)
* [Tables](our-data/tables/README.md)
* [Crosschain tables](our-data/tables/crosschain-tables.md)
* [Arbitrum Tables](our-data/tables/arbitrum-tables.md)
* [AAVE Tables](our-data/tables/aave-tables/README.md)
* [Market Stats](our-data/tables/aave-tables/market-stats.md)
* [Votes](our-data/tables/aave-tables/votes.md)
* [Proposals](our-data/tables/aave-tables/proposals.md)
* [Deposits](our-data/tables/aave-tables/deposits.md)
* [Liquidations](our-data/tables/aave-tables/liquidations.md)
* [Borrows](our-data/tables/aave-tables/borrows.md)
* [Repayments](our-data/tables/aave-tables/repayments.md)
* [Flashloans](our-data/tables/aave-tables/flashloans.md)
* [Withdraws](our-data/tables/aave-tables/withdraws.md)
* [Avalanche Tables](our-data/tables/avalanche-tables.md)
* [Algorand Tables](our-data/tables/algorand-tables/README.md)
* [Algorand Base Tables](our-data/tables/algorand-tables/algorand-base-tables/README.md)
* [Account](our-data/tables/algorand-tables/algorand-base-tables/account.md)
* [Account App](our-data/tables/algorand-tables/algorand-base-tables/account-app.md)
* [Account Asset](our-data/tables/algorand-tables/algorand-base-tables/account-asset.md)
* [App](our-data/tables/algorand-tables/algorand-base-tables/app.md)
* [Application Call Transaction](our-data/tables/algorand-tables/algorand-base-tables/application-call-transaction.md)
* [Asset](our-data/tables/algorand-tables/algorand-base-tables/asset.md)
* [Asset Configuration Transaction](our-data/tables/algorand-tables/algorand-base-tables/asset-configuration-transaction.md)
* [Asset Freeze Transaction](our-data/tables/algorand-tables/algorand-base-tables/asset-freeze-transaction.md)
* [Asset Transfer Transaction](our-data/tables/algorand-tables/algorand-base-tables/asset-transfer-transaction.md)
* [Block](our-data/tables/algorand-tables/algorand-base-tables/block.md)
* [Key Registration Transaction](our-data/tables/algorand-tables/algorand-base-tables/key-registration-transaction.md)
* [Payment Transaction](our-data/tables/algorand-tables/algorand-base-tables/payment-transaction.md)
* [Transactions](our-data/tables/algorand-tables/algorand-base-tables/transactions.md)
* [Transfers](our-data/tables/algorand-tables/algorand-base-tables/transfers.md)
* [Swaps](our-data/tables/algorand-tables/algorand-base-tables/swaps.md)
* [Transactions Participation](our-data/tables/algorand-tables/algorand-base-tables/transactions-participation.md)
* [Prices Swap](our-data/tables/algorand-tables/algorand-base-tables/prices-swap.md)
* [Prices Pool Balances](our-data/tables/algorand-tables/algorand-base-tables/prices-pool-balances.md)
* [Daily Balances](our-data/tables/algorand-tables/algorand-base-tables/daily-balances.md)
* [Astroport Tables](our-data/tables/astroport-tables/README.md)
* [Astroport Pool Reserves](our-data/tables/astroport-tables/lp-actions.md)
* [Astroport Swaps](our-data/tables/astroport-tables/swap.md)
* [BSC Tables](our-data/tables/bsc-tables.md)
* [Compound Tables](our-data/tables/compound-tables/README.md)
* [Repayments](our-data/tables/compound-tables/repayments.md)
* [Redemptions](our-data/tables/compound-tables/redemptions.md)
* [Deposits](our-data/tables/compound-tables/mints.md)
* [Liquidations](our-data/tables/compound-tables/liquidations.md)
* [Borrows](our-data/tables/compound-tables/borrows.md)
* [Market Stats](our-data/tables/compound-tables/market-stats.md)
* [Crosschain Tables](our-data/tables/crosschain-tables-1/README.md)
* [Crosschain Address Labels](our-data/tables/crosschain-tables-1/crosschain-address-labels.md)
* [Crosschain Address Tags](our-data/tables/crosschain-tables-1/crosschain-address-tags.md)
* [Ethereum Tables](our-data/tables/table-schemas/README.md)
* [Ethereum Transactions Table](our-data/tables/table-schemas/schemas.md)
* [Ethereum UDM Events Table](our-data/tables/table-schemas/ethereum-events.md)
* [Ethereum Events Emitted Table](our-data/tables/table-schemas/ethereum-events-emitted-table.md)
* [Ethereum Contracts Table](our-data/tables/table-schemas/ethereum-events-emitted-table-1.md)
* [ERC20 Balances Table](our-data/tables/table-schemas/daily-erc20-balances.md)
* [Ethereum NFT Tables](our-data/tables/table-schemas/ethereum-nft-tables/README.md)
* [NFT Metadata](our-data/tables/table-schemas/ethereum-nft-tables/nft-metadata.md)
* [NFT Events](our-data/tables/table-schemas/ethereum-nft-tables/nft-events.md)
* [Ethereum DEX Tables](our-data/tables/table-schemas/ethereum-dex-tables-uniswap-v2-style/README.md)
* [DEX Liquidity Pools](our-data/tables/table-schemas/ethereum-dex-tables-uniswap-v2-style/dex-liquidity-pools.md)
* [DEX Swaps](our-data/tables/table-schemas/ethereum-dex-tables-uniswap-v2-style/dex-swaps.md)
* [Ethereum\_Core Tables](our-data/tables/ethereum\_core-tables.md)
* [Ethereum Maker DAO Tables](our-data/tables/ethereum-maker-dao-tables.md)
* [Ethereum\_Sushi Tables](our-data/tables/ethereum\_sushi-tables.md)
* [FLOW Tables](our-data/tables/flow-tables/README.md)
* [Blocks](our-data/tables/flow-tables/blocks.md)
* [Bridge Transactions](our-data/tables/flow-tables/bridge-transactions.md)
* [Contract Labels](our-data/tables/flow-tables/contract-labels.md)
* [Events](our-data/tables/flow-tables/events.md)
* [NFT Sales](our-data/tables/flow-tables/nft-sales.md)
* [Prices](our-data/tables/flow-tables/prices.md)
* [Swaps](our-data/tables/flow-tables/swaps.md)
* [Token Transfers](our-data/tables/flow-tables/token-transfers.md)
* [TopShot Metadata](our-data/tables/flow-tables/topshot-metadata.md)
* [Transactions](our-data/tables/flow-tables/transactions.md)
* [Validator Labels](our-data/tables/flow-tables/validator-labels.md)
* [Gnosis Tables](our-data/tables/gnosis-tables.md)
* [NEAR Tables](our-data/tables/near-tables.md)
* [Optimism Tables](our-data/tables/optimism-tables.md)
* [Osmosis Tables](our-data/tables/osmosis-tables/README.md)
* [Osmosis Fact Airdrops](our-data/tables/osmosis-tables/osmosis-fact-airdrops.md)
* [Osmosis Fact Blocks Table](our-data/tables/osmosis-tables/osmosis-fact-blocks-table.md)
* [Osmosis Daily Balances](our-data/tables/osmosis-tables/osmosis-daily-balances.md)
* [Osmosis Fact Governance Proposal Deposits](our-data/tables/osmosis-tables/osmosis-fact-governance-proposal-deposits.md)
* [Osmosis Fact Governance Submit Proposal](our-data/tables/osmosis-tables/osmosis-fact-governance-submit-proposal.md)
* [Osmosis Fact Governance Votes](our-data/tables/osmosis-tables/osmosis-fact-governance-votes.md)
* [Osmosis Dim Labels](our-data/tables/osmosis-tables/osmosis-dim-labels.md)
* [Osmosis Fact Liquidity Provider Actions](our-data/tables/osmosis-tables/osmosis-fact-liquidity-provider-actions.md)
* [Osmosis Fact Msg Attributes Table](our-data/tables/osmosis-tables/osmosis-fact-msg-attributes-table.md)
* [Osmosis Fact Msgs Table](our-data/tables/osmosis-tables/osmosis-fact-msgs-table.md)
* [Osmosis Dim Prices](our-data/tables/osmosis-tables/osmosis-dim-prices.md)
* [Osmosis Fact Staking Rewards](our-data/tables/osmosis-tables/osmosis-fact-staking-rewards.md)
* [Osmosis Fact Staking](our-data/tables/osmosis-tables/osmosis-fact-staking.md)
* [Osmosis Fact Swaps](our-data/tables/osmosis-tables/osmosis-fact-swaps.md)
* [Osmosis Fact Transactions Table](our-data/tables/osmosis-tables/osmosis-fact-transactions-table.md)
* [Osmosis Fact Transfers](our-data/tables/osmosis-tables/osmosis-fact-transfers.md)
* [Osmosis Dim Vote Options](our-data/tables/osmosis-tables/osmosis-dim-vote-options.md)
* [Osmosis Fact Superfluid Staking](our-data/tables/osmosis-tables/osmosis-fact-superfluid-staking.md)
* [Polygon Tables](our-data/tables/polygon-tables/README.md)
* [Polygon Events Emitted](our-data/tables/polygon-tables/polygon-events-emitted.md)
* [Polygon Transactions](our-data/tables/polygon-tables/polygon-transactions.md)
* [Polygon UDM Events](our-data/tables/polygon-tables/polygon-udm-events.md)
* [Position Collected Fees](our-data/tables/polygon-tables/position-collected-fees.md)
* [Swaps](our-data/tables/polygon-tables/swaps.md)
* [V3 Resources](our-data/tables/polygon-tables/v3-resources.md)
* [Polygon 2.0 Tables](our-data/tables/polygon-2.0-tables.md)
* [Solana Tables](our-data/tables/solana-tables/README.md)
* [Solana Fact Blocks Table](our-data/tables/solana-tables/solana-fact-blocks-table.md)
* [Solana Fact Events Table](our-data/tables/solana-tables/solana-fact-events-table.md)
* [Solana Fact Gauges Votes](our-data/tables/solana-tables/solana-fact-gauges-votes.md)
* [Solana Fact Gov Actions](our-data/tables/solana-tables/solana-fact-gov-actions.md)
* [Solana Fact Proposal Votes](our-data/tables/solana-tables/solana-fact-proposal-votes.md)
* [Solana Dim Labels](our-data/tables/solana-tables/solana-dim-labels.md)
* [Solana Dim NFT Metadata Table](our-data/tables/solana-tables/solana-dim-nft-metadata-table.md)
* [Solana Fact NFT Mints](our-data/tables/solana-tables/solana-fact-nft-mints.md)
* [Solana Fact NFT Sales](our-data/tables/solana-tables/solana-fact-nft-sales.md)
* [Solana EZ Staking LP Actions](our-data/tables/solana-tables/solana-ez-staking-lp-actions.md)
* [Solana Fact Staking/LP Actions](our-data/tables/solana-tables/solana-fact-staking-lp-actions.md)
* [Solana Fact Swaps](our-data/tables/solana-tables/solana-fact-swaps.md)
* [Solana Fact Transactions Table](our-data/tables/solana-tables/solana-fact-transactions-table.md)
* [Solana Fact Transfers Table](our-data/tables/solana-tables/solana-fact-transfers-table.md)
* [Solana Fact Votes Block Agg](our-data/tables/solana-tables/solana-fact-votes-block-agg.md)
* [Solana Fact Proposal Votes Realms](our-data/tables/solana-tables/solana-fact-proposal-votes-realms.md)
* [Solana Fact Proposal Creation](our-data/tables/solana-tables/solana-fact-proposal-creation.md)
* [Terra Tables](our-data/tables/terra-tables/README.md)
* [Terra Raw Tables](our-data/tables/terra-tables/terra-raw-tables/README.md)
* [Blocks](our-data/tables/terra-tables/terra-raw-tables/blocks.md)
* [Msgs](our-data/tables/terra-tables/terra-raw-tables/msgs.md)
* [Msg\_events](our-data/tables/terra-tables/terra-raw-tables/msg\_events.md)
* [Transactions](our-data/tables/terra-tables/terra-raw-tables/transactions.md)
* [Transitions](our-data/tables/terra-tables/terra-raw-tables/transitions.md)
* [Terra Base Tables](our-data/tables/terra-tables/terra-base-tables/README.md)
* [Validator Labels](our-data/tables/terra-tables/terra-base-tables/validator-labels.md)
* [Labels](our-data/tables/terra-tables/terra-base-tables/labels.md)
* [Oracle Prices](our-data/tables/terra-tables/terra-base-tables/oracle-prices.md)
* [Tax Rate](our-data/tables/terra-tables/terra-base-tables/tax-rate.md)
* [Daily Balances](our-data/tables/terra-tables/terra-base-tables/daily-balances.md)
* [Swaps](our-data/tables/terra-tables/terra-base-tables/swap.md)
* [Staking](our-data/tables/terra-tables/terra-base-tables/staking.md)
* [Reward](our-data/tables/terra-tables/terra-base-tables/rewards.md)
* [Transfer Events](our-data/tables/terra-tables/terra-base-tables/transfer-events.md)
* [Event Actions](our-data/tables/terra-tables/terra-base-tables/event-actions.md)
* [Terraswap Tables](our-data/tables/terraswap-tables/README.md)
* [Terraswap LP Actions](our-data/tables/terraswap-tables/lp-actions.md)
* [Terraswap Pool Reserves](our-data/tables/terraswap-tables/lp-actions-1.md)
* [Terraswap Swaps](our-data/tables/terraswap-tables/swap.md)
* [THORChain Tables](our-data/tables/thorchain-tables/README.md)
* [THORChain Raw Table](our-data/tables/thorchain-tables/thorchain-raw-table/README.md)
* [Active Vault Events](our-data/tables/thorchain-tables/thorchain-raw-table/active-vault-events.md)
* [Inactive Vault Events](our-data/tables/thorchain-tables/thorchain-raw-table/inactive-vault-events.md)
* [Add events](our-data/tables/thorchain-tables/thorchain-raw-table/add-events.md)
* [Block Pool Depths](our-data/tables/thorchain-tables/thorchain-raw-table/block-pool-depths.md)
* [Bond Events](our-data/tables/thorchain-tables/thorchain-raw-table/bond-events.md)
* [Fee Events](our-data/tables/thorchain-tables/thorchain-raw-table/fee-events.md)
* [Gas Events](our-data/tables/thorchain-tables/thorchain-raw-table/gas-events.md)
* [Message Events](our-data/tables/thorchain-tables/thorchain-raw-table/message-events.md)
* [New Node Events](our-data/tables/thorchain-tables/thorchain-raw-table/new-node-events.md)
* [Pending Liquidity Events](our-data/tables/thorchain-tables/thorchain-raw-table/pending-liquidity-events.md)
* [Pool Balance Change Events](our-data/tables/thorchain-tables/thorchain-raw-table/pool-balance-change-events.md)
* [Pool Events](our-data/tables/thorchain-tables/thorchain-raw-table/pool-events.md)
* [Refund Events](our-data/tables/thorchain-tables/thorchain-raw-table/refund-events.md)
* [Reserve Events](our-data/tables/thorchain-tables/thorchain-raw-table/reserve-events.md)
* [Rewards Events](our-data/tables/thorchain-tables/thorchain-raw-table/rewards-events.md)
* [Rewards Event Entries](our-data/tables/thorchain-tables/thorchain-raw-table/rewards-event-entries.md)
* [Swap Events](our-data/tables/thorchain-tables/thorchain-raw-table/swap-events.md)
* [THORChain Base Table](our-data/tables/thorchain-tables/thorchain-base-table/README.md)
* [Block Rewards](our-data/tables/thorchain-tables/thorchain-base-table/block-rewards.md)
* [Bond Actions](our-data/tables/thorchain-tables/thorchain-base-table/bond-actions.md)
* [Daily Earnings](our-data/tables/thorchain-tables/thorchain-base-table/daily-earnings.md)
* [Daily Pool Stats](our-data/tables/thorchain-tables/thorchain-base-table/daily-pool-stats.md)
* [Daily TVL](our-data/tables/thorchain-tables/thorchain-base-table/daily-tvl.md)
* [Prices](our-data/tables/thorchain-tables/thorchain-base-table/prices.md)
* [Swaps](our-data/tables/thorchain-tables/thorchain-base-table/swaps.md)
* [Liquidity Actions](our-data/tables/thorchain-tables/thorchain-base-table/liquidity-actions.md)
* [Pool Block Balances](our-data/tables/thorchain-tables/thorchain-base-table/pool-block-balances.md)
* [Pool Block Fees](our-data/tables/thorchain-tables/thorchain-base-table/pool-block-fees.md)
* [Pool Block Statistics](our-data/tables/thorchain-tables/thorchain-base-table/pool-block-statistics.md)
* [Total Block Rewards](our-data/tables/thorchain-tables/thorchain-base-table/total-block-rewards.md)
* [Total Value Locked](our-data/tables/thorchain-tables/thorchain-base-table/total-value-locked.md)
* [Transfers](our-data/tables/thorchain-tables/thorchain-base-table/transfers.md)
* [Upgrades](our-data/tables/thorchain-tables/thorchain-base-table/upgrades.md)
* [Uniswap V3 Tables](our-data/tables/uniswap-v3-tables/README.md)
* [Pools](our-data/tables/uniswap-v3-tables/pools.md)
* [Pool Stats](our-data/tables/uniswap-v3-tables/pool-stats.md)
* [Positions](our-data/tables/uniswap-v3-tables/positions.md)
* [LP Actions](our-data/tables/uniswap-v3-tables/lp-actions.md)
* [Data Tutorials](our-data/tutorials/README.md)
* [Overview of Schemas & Tables](our-data/tutorials/overview-of-schemas-and-tables.md)
* [Algorand Tutorials](our-data/tutorials/algorand-tutorials.md)
* [Ethereum Tutorials](our-data/tutorials/ethereum-tutorials/README.md)
* [Getting Started with Ethereum Events](our-data/tutorials/ethereum-tutorials/getting-started-with-ethereum-events.md)
* [Getting Started with Ethereum ERC20 Balances](our-data/tutorials/ethereum-tutorials/getting-started-with-ethereum-erc20-balances.md)
* [Using Labels to Break Down Token Supply](our-data/tutorials/ethereum-tutorials/using-labels-to-break-down-token-supply.md)
* [Finding Centralized Exchange Deposits and Withdrawals](our-data/tutorials/ethereum-tutorials/finding-centralized-exchange-deposits-and-withdrawals.md)
* [MakerDAO Tutorials](our-data/tutorials/getting-started-with-dai-events.md)
* [Solana Tutorials](our-data/tutorials/solana-tutorials/README.md)
* [Solana Schema & Tables: Video Walkthrough](our-data/tutorials/solana-tutorials/solana-schema-and-tables-video-walkthrough.md)
* [Solana Specialty Tables: Video Walkthrough](our-data/tutorials/solana-tutorials/solana-specialty-tables-video-walkthrough.md)
* [Exploring Transactions in solana.events](our-data/tutorials/solana-tutorials/exploring-transactions-in-solana.events.md)
* [THORChain Tutorials](our-data/tutorials/thorchain-tutorials/README.md)
* [THORChain Schema & Tables](our-data/tutorials/thorchain-tutorials/thorchain-schema-and-tables.md)
* [Calculating IL for THORChain](our-data/tutorials/thorchain-tutorials/calculating-il-for-thorchain.md)
* [Contribute to Flipside Data](our-data/contribute-to-flipside-data.md)
## Flipside App <a href="#velocity" id="velocity"></a>
* [Getting Started with the Flipside App](velocity/getting-started-with-the-flipside-app.md)
* [Parameterized Queries](velocity/parameterized-queries.md)
* [Query Editor Shortcuts](velocity/query-editor-shortcuts.md)
## ShroomDK (SDK)
* [🍄 Getting Started](shroomdk-sdk/getting-started.md)
* [🛠 SDKS](shroomdk-sdk/sdks/README.md)
* [Javascript/Typescript](shroomdk-sdk/sdks/javascript-typescript.md)
* [🐍 Python SDK](shroomdk-sdk/sdks/python-sdk.md)
* [R](shroomdk-sdk/sdks/r.md)
* [🔗 RestAPI](shroomdk-sdk/restapi.md)
* [📄 Query Pagination](shroomdk-sdk/query-pagination/README.md)
* [JS/TS Pagination Example](shroomdk-sdk/query-pagination/js-ts-pagination-example.md)
* [🐍 Python SDK Pagination Example](shroomdk-sdk/query-pagination/python-sdk-pagination-example.md)
* [🔗 REST API Pagination Example](shroomdk-sdk/query-pagination/rest-api-pagination-example.md)
* [🛑 Rate Limits](shroomdk-sdk/rate-limits.md)

View File

@ -0,0 +1,90 @@
---
description: >-
A guide to data curation within Flipside. Currently only Avalanche and
Ethereum repositories are setup for community curation.
---
# Contribute to Flipside Data
## Access
#### Snowflake (ask in #community-curation-beta discord channel)
Hi , Im interested in doing data curation for Flipside, could you give me snowflake access please? Id like my username to be: `community_<insert_username>`
#### dbt cloud \[Optional]
Sign up on your own: [https://www.getdbt.com/signup/](https://www.getdbt.com/signup/)
### **Software Setup**
* (Optional) Install dbt on your terminal:[ https://docs.getdbt.com/dbt-cli/install/overview](https://docs.getdbt.com/dbt-cli/install/overview)
* Install Git (if you dont have it):[ https://git-scm.com/book/en/v2/Getting-Started-Installing-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
* Download Docker desktop: [https://docs.docker.com/get-docker/](https://docs.docker.com/get-docker/)
* Install VSCode: [https://code.visualstudio.com/download](https://code.visualstudio.com/download)
### **Project Setup**
1. Clone the project you want to work on from [FlipsideCrypto Github Org](https://github.com/FlipsideCrypto)
* Example for Ethereum: `git clone https://github.com/FlipsideCrypto/ethereum-models.git`
2. Open the project in VSCode
3. Create a `.env` file in the root directory of your project (note: the .env file will not be committed to the source)
* There is a provided `.env.sample` in the repository you may use as reference to create `.env`
4. Start a new branch in the repository
* Ensure you have the latest pulled down from the `main` branch
* `git checkout main`
* `git pull`
* Branch name should follow convention: `community/<branch_name>`
* Ex: `git checkout -b community/my-new-model`
5. Start dbt console (this is where you will run your models to have them deployed to snowflake)
* `make dbt-console`
6. Within the console, run `dbt debug` to ensure all connections are working
**You are now ready to write your first data model!**
### **Creating your first model**
1. Understand the modeling structure
* Data models iterate through different “layers”. Generally speaking these are bronze, silver, and core.
* Bronze is raw data layer
* Silver is intermediate data modeling layer
* Core is the presentation layer, aka what is exposed to the public
* **Most of the time you will be working within the silver layer**
2. Create model file within the proper layer and naming convention
* Naming convention for file is `<layer name>__<table name>.sql`
* Example for silver layer: **** `./models/silver/silver__my_new_table.sql`
3. Create a corresponding .yml file
* This should hold any model/column descriptions and tests for the model/columns
* Example for silver layer: **** `./models/silver/silver__my_new_table.yml`
4. Start writing SQL code
* Write code in Snowflake Web UI (Snowsight): [https://app.snowflake.com/us-east-1/vna27887](https://app.snowflake.com/us-east-1/vna27887)
* Snowsight documentation: [https://docs.snowflake.com/en/user-guide/ui-snowsight.html](https://docs.snowflake.com/en/user-guide/ui-snowsight.html)
5. Turn SQL code into DBT SQL
* dbt combines sql with Jinja, see more:[ https://docs.getdbt.com/docs/building-a-dbt-project/jinja-macros](https://docs.getdbt.com/docs/building-a-dbt-project/jinja-macros)
* Copy sql code into the file created earlier
* Add config section
* See existing models for examples
* Dbt docs for available configurations [https://docs.getdbt.com/reference/resource-configs/snowflake-configs](https://docs.getdbt.com/reference/resource-configs/snowflake-configs)
* Convert SQL elements into Jinja
* Commonly this is changing table name to references and adding incremental loading logic
* Ref: [https://docs.getdbt.com/reference/dbt-jinja-functions/ref](https://docs.getdbt.com/reference/dbt-jinja-functions/ref)
* Incremental logic: [https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models](https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models)
1. See existing curated models for examples on how to implement incremental logic. `ethereum-models/models/silver/silver__transactions.sql`
6. Run the dbt model to put it into the community dev database. You must run this command within the dbt-console. If you have exited the console run `make dbt-console` again
* `dbt run -s <path to model>`
* Run: [https://docs.getdbt.com/reference/commands/run](https://docs.getdbt.com/reference/commands/run)
* If this is your 1st time using `dbt run` in this docker container, you may need to run `dbt deps` command
* Models will be deployed to `<BLOCKCHAIN>_COMMUNITY_DEV` database within Snowflake. This database refreshes daily at `04:00 AM UTC`, any non-production resources will be erased.
7. Run the test file
* `dbt test -s <path to mode>`
* Tests: [https://docs.getdbt.com/docs/building-a-dbt-project/tests](https://docs.getdbt.com/docs/building-a-dbt-project/tests)
8. Create GitHub Pull Request and write a summary on your updates/changes, as well as attaching passing test logs
9. Request Reviewer from one of the GitHub handles below
* austinFlipside
* juls858
* James-Mission
* desmond-hui
10. Fix Review Comments
11. Re-Request Reviewer after fixing review comments
12. If your PR has been approved, merge it to production
13. **Congratulations! Youve successfully contributed a data model!**

View File

@ -0,0 +1,23 @@
---
description: >-
The Data Models section provides an overview of Flipside's cross-chain
blockchain data schemas.
---
# Data Model Overview
Flipside's on-chain data is organized around a common set of data models. These common models provide a standard interface that makes it simple to perform analysis across a variety of blockchains without having to learn a new schema each time.&#x20;
To date, Flipside has parsed over 60+ blockchains leveraging our Chainwalking technology. For each blockchain parsed, data is cleaned and normalized into the following models:
1. **Events** - events represent the distillation of all interactions that occur within a transaction. For example, transfers, rewards, staking, internal transactions, smart contract calls, etc.
2. **Address Balances** - balance readings are taken each time an address is involved in a transaction.
All tables are enriched with [Flipsides Labels](labels/).&#x20;
Let's start by exploring Flipside's [event model](events-data-model.md).&#x20;
{% content-ref url="events-data-model.md" %}
[events-data-model.md](events-data-model.md)
{% endcontent-ref %}

View File

@ -0,0 +1,24 @@
# Address Balance Model
Flipside records the balance for every address that is involved within a transaction, in addition to account for such things as genesis allocation and mint-time distributions.&#x20;
Balances for each address are rolled up into a daily balance table, account for every address we've seen on the network.
#### Daily Balance Table Schema
| Field | Description |
| ------------- | ------------------------------------------------------------ |
| date | The date the balance was recorded. |
| address | The address the balance was recorded for. |
| balance | The decimal adjusted balance recorded for the address. |
| balance\_usd | The USD equivalent of the recorded balance. |
| balance\_type | The type of balance, i.e. 'liquid', 'staked', 'locked', etc. |
| currency | The on-chain asset being recorded. |
#### Dataset Features:
* Current day data is updated throughout the day to provide an up-to-date reading of balances.&#x20;
* If an account is inactive one day, their previous day's balance is carried forward.
* The currency field denotes which on-chain asset is being recorded.
* Addresses are labeled according to our Label System.&#x20;
* Label fields are left blank (NULL) if the address is unlabeled.

View File

@ -0,0 +1,60 @@
# UDM Events Model
An event in Flipside's data model represents the distillation of all interactions that occur within a transaction. An event could range from a simple transfer between two parties to more complex smart contract calls.
![](<../../.gitbook/assets/Velocity Documentation - EventContext (1).png>)
## UDM Event Model
The event model is represented for each chain as a single table. For example _"_"_ethereum.udm\_events_". The event model can conceptually be broken down into 2 core components, **parent context data** corresponding to the event and the **event data** itself.
![](<../../.gitbook/assets/Velocity Documentation - Page 1.png>)
### Parent Context Data
Depending on the chain, a single transaction may consist of several "child" events.
To consistently represent the 1-to-many relationship, you will see 1 row that represents each transaction (including the fee for issuing the transaction) and then 1 or more rows representing all other events that are generated by this transaction.
All of these rows are grouped by their parent transaction metadata:
#### Block Context:
The following block-level metadata allows for block-level grouping of events.
| Field | |
| ---------------- | ------------------------------------------- |
| block\_timestamp | UTC timestamp when the block was confirmed. |
| block\_number | The block height. |
#### Transaction Context:
| Field | |
| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| tx\_id | A unique identifier of the transaction, typically a transaction hash. |
| tx\_type | Transaction type is used to distinguish the top-level transaction type, e.g. reward distribution, delegation, validator creation, or any smart contract function call on a chain like Ethereum. |
| tx\_from | The address that initiated the transaction. |
| tx\_to | The address of the transaction recipient. |
| tx\_fee | The decimal adjusted fee associated with the transaction. |
| tx\_fee\_usd | The USD equivalent value of fee at transaction time. |
{% hint style="info" %}
When you are looking at more complicated behaviors, you may want to filter by particular tx\_type first, then look at the "child" events for all transactions in this subset.
{% endhint %}
{% hint style="warning" %}
Note: On Ethereum, the tx data is broken out into its own separate table. All other chains follow a 1 table rule for the Events data model. Check-out the specific Ethereum documentation for more details there.&#x20;
{% endhint %}
### Event Data
| Field | Description |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| event\_from | The initiator of the event. |
| event\_to | The recipient of the event. |
| event\_type | The type of event, specific to each blockchain, for example, "transfer", "reward", "stake", "mint", etc. |
| event\_currency | If applicable, the on-chain asset involved in the event. |
| event\_amount | If applicable, the decimal adjusted amount involved in the event (this is typically present when the event\_type is a "transfer") |
| event\_amount\_usd | If applicable, the USD equivalent value sent at transaction time (this is typically present when a market exists for the event\_currency involved) |
Next, we'll dive into Flipside's [balance model](balances.md).

View File

@ -0,0 +1,23 @@
# Facts and Dimensions
What are facts and dimensions?
Facts and dimensions are a part of what is called a star schema. Star schema is a mature modeling approach widely adopted by relational data warehouses. It requires modelers to classify their model tables as either dimension or fact.
_**Fact tables**_ store observations or events, and can be blocks, transactions, mints, swaps, etc.
_**Dimension tables**_ describe entities—the things you analyze. Entities can include labels, prices, decimals, tags, etc
The key here is that:
* _**Dimensions**_ support filtering and grouping
* _**Facts**_ support summarization
This type of modeling is a logical design technique used to structure data so that it is intuitive to users and delivers fast query performance. What makes the star schema stand out is its simplicity and ability to be understood by users.
The schema works by dividing data into measurements and the “who, what, where, when, why, and how” descriptive context. Broadly, these two groups are facts and dimensions.
Lets do a crypto transaction for an example
* The amount you spent and how many items you bought would be considered a fact, but what exchange rate and what blockchain would be considered dimensions.
* Once these two groups have been established, we can connect them by the unique transaction number associated with your specific purchase.

View File

@ -0,0 +1,49 @@
# Labels
Labels identify known addresses that are associated with a CEX, DEX, NFT project, liquidity pool, or other entity. Each known address receives only one label, and that label is considered a "source of truth" for that address. Not every address has a label.&#x20;
See [the Crosschain schema](../../tables/crosschain-tables-1/crosschain-address-labels.md) for a table containing all labeled addresses.&#x20;
Flipside applies a 2-level hierarchy to all labeled addresses using 4 field attributes.&#x20;
![](<../../../.gitbook/assets/Velocity Documentation - Labels.png>)
| creator | Name of the creator of the label |
| --------------------- | ----------------------------------------------------------------------------------------------- |
| label\_type | A high-level category describing the addresses main function or ownership (e.g. exchange) |
| label\_subtype | A sub-category nested within label type providing further detail (e.g. exchange deposit wallet) |
| project\_name (label) | The name of the entity that controls the address (e.g. Binance). |
| address\_name | A description of the use of the address by the controlling entity (e.g. Binance deposit wallet) |
Note: on Event and Balance tables there is no need to join a secondary table to group or filter by label attributes .
{% hint style="info" %}
Events and Balance tables are automatically enriched with label columns corresponding to any column that contains an address type. The pattern for these columns names is: `{address_function}_{label_attribute}`
{% endhint %}
For example, in an events table, the following columns would be present to account for labels on the `event_from` . These would also exist for `event_to`, `tx_from`,`tx_to`, etc.
```
event_from_label_type
event_from_label_subtype
event_from_label
event_from_address_name
```
## Label Types
There are 10 label types within any blockchain.
1. ****[**cex** (Centralized Exchange)](cex-label-type.md)
2. ****[**dex** (Decentralized Exchange)](dex-label-type.md)
3. ****[**operator** (Chain Operations)](operator-label-type.md)
4. ****[**chadmin** (Chain Administration)](chadmin-label-type.md)
5. ****[**defi** (Decentralized Finance Applications)](dex-label-type.md)
6. ****[**nft** (NonFungible Token Contracts & Applications)](nft-label-type.md)
7. ****[**layer2** (Layer 2 Dapps)](layer2-label-type.md)
8. ****[**dapp** (Decentralized Applications)](other-label-type.md)
9. ****[**token** (Token Contracts)](token-label-type.md)
10. ****[**flotsam** (Junk or Other)](flotsam-label-type.md)

View File

@ -0,0 +1,19 @@
# Centralized Exchange Label Type
Centralized Exchanges are referred to as `cex` in the Flipside label system.&#x20;
`label_type` = `cex`
### Label Subtypes
| Subtype | Description |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `hot_wallet` | Centralized exchange hot wallets -- addresses that collect funds from deposit wallets, send withdrawals to customers, and hold the majority of the exchanges funds |
| `deposit_wallet` | Centralized exchange deposit wallets |
| `cold_wallet` | A wallet used to hold rarely used funds belonging to the exchange |
| `chadmin` | A administration address belonging to the exchange |
| `contract_deployer` | A contract belonging to the exchange that is used to create other contracts |
| `general_contract` | A general use contract belonging to the exchange |
| `multisig` | A general use multisig wallet belonging to the exchange |
| `token_contract` | Contract of a token owned by the exchange |

View File

@ -0,0 +1,15 @@
# Chain Admin Label Type
Addresses that are used for administrative purposes on the blockchain, including chain-wide foundation addresses are labeled as `chadmin` .
`label_type` = `chadmin`
### Label Subtypes <a href="#label-subtypes" id="label-subtypes"></a>
| Subtype | Description |
| ------------------ | ----------------------------------------------------------------------- |
| `genesis` | The mint or burn addresses of a chain (the all 0's address on Ethereum) |
| `foundation` | Addresses used by the chain foundation |
| `general_contract` | Other chadmin contracts |

View File

@ -0,0 +1,27 @@
# Decentralized Finance Label Type
The `defi` label type represents addresses used for minting.
`label_type` = `defi`
``
### Label Subtypes
| Subtype | Description |
| ------------------- | -------------------------------------------------------------------------------- |
| `token_contract` | Contract of a token belonging to the defi project |
| `pool` | Any type of pool address, i.e. farming, staking, liquidity etc. |
| `vault` | A vault controlled by the defi project |
| `fee_wallet` | Wallet for fees collected by the defi project |
| `dao` | An address controlling a DAO controlled by the defi project |
| `voting` | Address controlled by the defi project used for voting |
| `chadmin` | Addresses used for administrative purposes controlled by the defi project |
| `contract_deployer` | A contract controlled by the defi project that is used to create other contracts |
| `treasury` | Treasury addresses where the defi project has a treasury |
| `governance` | Governance addresses where the defi project has governance |
| `rewards` | Addresses used to distribute rewards |
| `oracle` | A contract used as an oracle by the defi project |
| `token_sale` | Addresses used in initial token sales and distributions |
| `general_contract` | A contract belonging to the defi project |
| `multisig` | A multisig contract belonging to the defi project |

View File

@ -0,0 +1,26 @@
# Decentralized Exchange Label Type
The `dex` label type represents any foundation controlled address.
`label_type` = `dex`
### Label Subtypes
| Subtype | Description |
| -------------------- | ------------------------------------------------------------------------------------------ |
| `swap_contract` | The contract used by the dex to facilitate token exchanges |
| `token_contract` | Contract of a token belonging to the decentralized exchange |
| `pool` | Any type of pool address, i.e. farming, staking, liquidity etc. |
| `vault` | A vault controlled by the decentalized exchange |
| `fee_wallet` | Wallet for fees collected by the decentalized exchange |
| `dao` | An address controlling a DAO controlled by the decentalized exchange |
| `chadmin` | Addresses used for administrative purposes controlled by the decentalized exchange |
| `contract_deployer` | A contract controlled by the decentralized exchange that is used to create other contracts |
| `foundation` | Foundation addresses where the decentralized exchange has a foundation |
| `governance` | Governance addresses where the decentralized exchange has governance |
| `rewards` | Addresses used to distribute rewards |
| `strategy` | Addresses used to control strategy |
| `token_distribution` | Addresses used to distribute supply |
| `token_sale` | Addresses used in initial token sales and distributions |
| `general_contract` | A contract belonging to the exchange |
| `multisig` | A multisig contract belonging to the decentralized exchange |

View File

@ -0,0 +1,15 @@
# Flotsam Label Type
Label category reserved for junk, scams, and other known addresses that do not belong to a "legitimate" project but also should not be assumed to be "users". Some labels are descriptive (i.e. "upbit hack") in this category and some are not (i.e. "phishing scam").
`label_type` = `flotsam`
### Label Subtypes
| Subtype | Description |
| ------------------- | -------------------------------------------------------- |
| `toxic` | Scams, pyramid schemes, bad bots, attacks, hackers, etc. |
| `token_contract` | ERC-20 token (fungible token) contract |
| `general_contract` | A general contract |
| `contract_deployer` | A contract used to create other contracts |
| `donation_address` | Addresses used to collect donations |

View File

@ -0,0 +1,12 @@
# Layer Two Label Type
Projects building layer two's.
`label_type` = `layer2`
### Label Subtypes
| Subtype | Description |
| ------------------ | --------------------------------------------------------------------- |
| `token_contract` | ERC-20 token (fungible token) contract owned by the layer two project |
| `general_contract` | A contract controlled by the layer two project |

View File

@ -0,0 +1,17 @@
# NonFungible Tokens Label Type
An `nft` label type represents any nonfungible token project or a nft marketplace.
`label_type` = `nft`
### Label Subtypes
| Subtype | Description |
| ------------------- | ------------------------------------------------------------------------------ |
| `token_contract` | ERC-20 token (fungible token) contract owned by the nft project or marketplace |
| `nf_token_contract` | NonFungible token contract owned by the nft project or marketplace |
| `contract_deployer` | A contract used by the project to create other contracts |
| `fee_contract` | A contract used by the project to collect fees |
| `marketplace` | A contract used by a marketplace to facilitate sales and trades of nft's |
| `general_contract` | A contract controlled by the nft project or marketplace |

View File

@ -0,0 +1,14 @@
# Operator Label Type
Addresses that are necessary for the function of a blockchain or project ecosystem are referred to as `operator` .
`label_type` = `operator`
### Label Subtypes
| Subtype | Description |
| ------------- | ----------------------------------------------------- |
| `validator` | Addresses that run nodes and/or validate blocks |
| `mining_pool` | Known mining pools |
| `solo_miner` | An individual address that has received block rewards |

View File

@ -0,0 +1,18 @@
# Decentralized Applications Label Type
`Decentralized Applications (Dapps) that don't fit into the defi, nft or layer2 categories.`
`label_type` = `dapp`
### Label Subtypes
| Subtype | Description |
| --------------------- | ----------------------------------------------------------------------- |
| `contract_deployer` | Non-exchange financial services such as mixers and payment services |
| `fee_wallet` | Walled used by the dapp to collect fees |
| `token_contract` | Contract of a token belonging to the dapp |
| `token_sale` | Address used in the initial token sale of a token belonging to the dapp |
| `treasury` | Address used by the treasury of the dapp |
| `oracle` | Oracle contract |
| `donation_address` | Address used by the dapp to collect donations |
| `aggregator_contract` | Aggregator contract |

View File

@ -0,0 +1,11 @@
# Token Label Type
Label for token contracts that are stand-alone, i.e. they do not belong to a project that has any other addresses. Stand-alone stablecoins get this label type too, i.e. WETH.&#x20;
### Label Subtypes
| Subtype | Description |
| ---------------- | --------------------------------------- |
| `token_contract` | ERC-20 token (fungible token) contract |

View File

@ -0,0 +1,149 @@
# Tags
Tags identify traits or behaviors that belong to an address.&#x20;
For a table of all tagged addresses see [the Crosschain schema](../tables/crosschain-tables-1/crosschain-address-tags.md).&#x20;
Do you often copy/paste lists of addresses into your queries? Tags are for you. Tags can be specific and provable, e.g. "OpenSea user", or simply a tool to group addresses and clean up your code.&#x20;
Your tags. Your rules.&#x20;
## How are tags different than labels?&#x20;
Tags are more unstructured and free-form than labels. An address's tags can be provable and durable, or subjective and temporary. An address can have as many tags as desired.&#x20;
In contrast labels serve as a "source of truth" for an address, and are used to label known addresses that are associated with a CEX, DEX, NFT project, liquidity pool, or other entity. An address can have only one label.&#x20;
## What do our tags look like?
Our tags use a 2-level hierarchy, just like our labels. \
| tag\_type | <p>A high-level category describing the address' main function or ownership </p><p>(i.e. NFT)</p> |
| --------- | ------------------------------------------------------------------------------------------------- |
| tag\_name | <p>A sub-category of tag_type providing further detail </p><p>(e.g. Moonbird Holder)</p> |
**Tags example:**
| tag\_type | tag\_name |
| --------- | ------------- |
| Celebrity | Steve Aoki |
| Celebrity | Mark Cuban |
| Celebrity | Justin Bieber |
Using tag_\__type you can pull all celebrities tagged by the Flipside community, or use tag\_name to pull a specific celebrity.
## The tags table
The data for our tags is stored in the data table: [crosschain.core.address\_tags](../tables/crosschain-tables-1/crosschain-address-tags.md). \
| Column Name | Data type | Description |
| ----------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| blockchain | string | The blockchain that the address belongs to. |
| creator | string | Who created the tag. Use your Flipside username, shown in your Flipside profile URL, for tags you create. |
| address | string | The address of the contract or wallet the tag describes. |
| tag\_name | string | Tag name (sub-category) |
| tag\_type | string | Tag type (high-level category) |
| start\_date | timestamp | Date the tag first applies. For tags that are permanent, this might be the date the address had its first behavior that warrants its tag, or the addresses' first transaction (e.g. if the tag identifies a celebrity NFT address). |
| end\_date | timestamp | Date the tag no longer applies (for tags that are permanent or currently active, end\_date can be NULL) |
| **tag\_created\_at \*** | timestamp | Timestamp for when the tag was inserted into our data. |
\* tag\_created\_at is auto-generated by Flipside.
## How to add tags
There are 3 ways to add tags to our data!\
\
**1. Add a SQL statement to our GitHub**\
\
You can use a Flipside query to create a tag set that will run on a reoccurring basis. This is a very powerful and scalable way to create a dynamic tag set that can update regularly. \
\
Please see our [Github](https://github.com/FlipsideCrypto/crosschain-models) for how to upload your tag set queries. \
\
**2. Add a DBT seed file to our GitHub**\
\
If you have a static list of addresses that need a tag, a DBT seed file is the best route. This is the most efficient method to tag a list of addresses that will not change and don't rely on a SQL query. \
\
Please see our [Github](https://github.com/FlipsideCrypto/crosschain-models) for how to upload your own DBT seed files.\
\
**3. I know what I want but I don't know how to tag**\
****\
****Flipside has a very active community and extraordinarily helpful employees. Reach out to the community, or to @gto, in Discord and someone will help you set up your tags.&#x20;
## How to query tags
It's important to remember that a particular address can (and should) have multiple tags.&#x20;
**BE CAREFUL WHEN JOINING TO THE TAGS TABLE, SO YOU DON'T DUPLICATE ROWS.**&#x20;
A common use-case for tags is to exclude addresses that are contracts from an analysis. A query such as:
```
select
address
from crosschain.core.address_tags
where tag_name = 'contract address'
limit 100
```
will return a list of all addresses that are contracts.&#x20;
Another use-case is to find addresses that are active on multiple EVM's. For our example, lets say active on both Ethereum and Avalanche. For this example a query such as:
```
select
distinct address
from crosschain.core.address_tags
where tag_name in ('active on ethereum last 7', 'active on avalanche last 7')
limit 100
```
will return a list of addresses that are active on both Ethereum and Avalanche. \
\
\
Our tags are augmented by our start\_date and end\_date fields, which allows you to see tags historically!\
A simple query like:
```
select
distinct address
from crosschain.core.address_tags
where tag_name = 'active on ethereum last 7'
limit 100
```
will return a list of addresses that were _ever_ active on Ethereum. \
A query such as:
```
select
distinct address
from crosschain.core.address_tags
where tag_name = 'active on ethereum last 7'
and end_date is null
limit 100
```
will return a list of addresses that were active _in the last 7 days!_\
__We can also use the start and end dates to find addresses that were active in a date range! A query such as:
```
select
distinct address
from crosschain.core.address_tags
where tag_name = 'active on ethereum last 7'
and start_date < '2021-07-01'
and (end_date >= '2021-06-01' or end_date is null)
limit 100
```
will return a list of addresses that were active on Ethereum during June 2021.

33
our-data/data-updates.md Normal file
View File

@ -0,0 +1,33 @@
---
description: >-
Important updates about the blockchain data publicly available through
Flipside SQL editor
---
# Data Updates
## **For More information on new databases and three part naming, please see** [**this document**](https://docs.google.com/document/d/1swYTBHYNoY27Mz5FB2Ru0KNTLRhwX6imWQtlyW5F-7Q/edit)****
**Solana Schema**
Solana will be have its own database starting early June 2022! We will move it from
flipside\_prod\_db --> solana
Your queries and dashboards will continue to work for a period of time. To future proof your dashboards, you should move over **all work** to the three part naming convention in the new solana database.&#x20;
****
**Ethereum Schema**
**Ethereum will have its own database starting May 25, 2022! flipside\_prod\_db.ethereum\_core will still be supported until June. We are actively making infrastructure upgrades and it will replace both flipside\_prod\_db.ethereum and ethereum\_core.**&#x20;
New Ethereum tables will be released in April 2022!
The new Ethereum schema will be **ethereum\_core**. Ethereum was one of the first blockchains that was developed within Flipside and there have been upgrades to infrastructure, warehousing, model building, etc. The Flipside developers have been working on what is being called the Ethereum facelift where many of the tables have been re-built from the ground up taking into account user feedback, usage, and lessons learned.&#x20;
Timeline:\
\- April 18, 2022 - Eth Week! New Schema exposed for all users. All bounties will have to use ethereum\_core schema.\
\
__

30
our-data/tables/README.md Normal file
View File

@ -0,0 +1,30 @@
---
description: >-
This section provides documentation on the schemas and design decisions behind
every queryable table.
---
# Tables
Table level guides are organized by blockchain or blockchain project. Within each table guide, you will find a column by column breakdown describing the specifics of the schema.&#x20;
### Table Documentation
{% content-ref url="table-schemas/" %}
[table-schemas](table-schemas/)
{% endcontent-ref %}
{% content-ref url="table-schemas/ethereum-nft-tables/" %}
[ethereum-nft-tables](table-schemas/ethereum-nft-tables/)
{% endcontent-ref %}
{% content-ref url="compound-tables/" %}
[compound-tables](compound-tables/)
{% endcontent-ref %}
{% hint style="info" %}
New blockchains/blockchain projects are added regularly.
{% endhint %}

View File

@ -0,0 +1,77 @@
# AAVE Tables
AAVE is a lending platform, somewhat similar in scope and design to Compound. As a result we have a similar design schema for this project. Feedback remains very welcome as much of this data remains very beta!
### New Tables (Compared to Compound)
Unlike for Compound there are three further tables:
* _Aave votes and proposals:_ Governance actions do exist on Compound and in fact can even be found within the events data, however with AAVE we've begun to opt to give these their own tables. These come as a pair -- proposals tracks all ongoing proposals and their current status, votes tracks votes for and against their proposals. The two can be joined on proposal ID.
* _Flashloans:_ AAVE has explicit support for flashloans -- loans taken and repaid within the same transaction. Once again on Compound this is technically possible but AAVE has flashloans built in as their own set of functions.
### Variable and Stable Debts
Additionally a key feature of AAVE's lending markets is that each market (i.e. USDC) supports two types of loans, one at a stable borrow rate and another at a variable rate. Both V1 and V2 (and AMM), support these but V2 and up has an additional feature aimed direct at these types of loans -- debt tokens.
Debt tokens tokenize debt in the same way aTokens (or Compounds' cTokens) tokenize amounts supplied to the market. aTokens are given to suppliers proportionally based on how much they supply to that market. Stable Debt Tokens are given to borrowers based on how much debt at a stable borrow rate they have from that market. Identically Variable Debt Tokens are given to borrowers based on how much variable debt they hold
### What about the Version columns (and blockchain)?
![](<../../../.gitbook/assets/Screen Shot 2021-08-16 at 3.22.45 PM.png>)
Aave a few different subsets of markets, shown above.&#x20;
AAVE V1: Debt tokens do not exist and more technically, (though less significantly for our data) all interactions are done through the Lending Pool. aTokens do exist and stable/variable borrow rates are still available
AAVE V2: Debt tokens exist to more easily track outstanding debt. Direct interactions are split among a Lending Pool and a Data Provider contract (though not necessary for anyone not planning to interact with the protocol directly on chain, i.e. app developers)
AAVE AMM: Identical in design to AAVE V2 though it uses its own set of contracts. Designed for pool tokens.
AAVE Polygon: Also shares a design with V2, with the key difference is that it is on the Polygon chain (whereas all others are Ethereum only)
### General
{% content-ref url="market-stats.md" %}
[market-stats.md](market-stats.md)
{% endcontent-ref %}
### Governance
{% content-ref url="votes.md" %}
[votes.md](votes.md)
{% endcontent-ref %}
{% content-ref url="proposals.md" %}
[proposals.md](proposals.md)
{% endcontent-ref %}
### Supplying
{% content-ref url="withdraws.md" %}
[withdraws.md](withdraws.md)
{% endcontent-ref %}
{% content-ref url="deposits.md" %}
[deposits.md](deposits.md)
{% endcontent-ref %}
### Liquidations
{% content-ref url="liquidations.md" %}
[liquidations.md](liquidations.md)
{% endcontent-ref %}
### Borrowing
{% content-ref url="borrows.md" %}
[borrows.md](borrows.md)
{% endcontent-ref %}
{% content-ref url="repayments.md" %}
[repayments.md](repayments.md)
{% endcontent-ref %}
{% content-ref url="flashloans.md" %}
[flashloans.md](flashloans.md)
{% endcontent-ref %}

View File

@ -0,0 +1,26 @@
# Borrows
Borrows exist within the `aave` schema, as `aave.borrows`
| Field | Type | Description |
| ----------------------- | --------- | --------------------------------------------- |
| `tx_id` | string | Transaction ID for this liquidation |
| `block_id` | number | The block height this event was recorded at |
| `block_timestamp` | timestamp | UTC timestamp for this transaction |
| `event_index` | number | Index of this event within the transaction |
| `aave_market` | address | Address of the token |
| `aave_token` | address | Address of the aToken |
| `borrowed_tokens` | number | Amount of tokens borrowed |
| `borrowed_usd` | number | USD amount borrowed |
| `borrower_address` | address | Address of the borrower |
| `borrow_rate_mode` | string | Either variable or stable |
| `lending_pool_contract` | address | Address of the lending pool contract |
| `aave_version` | string | AAVE version (V1, V2, or AMM for Ethereum) |
| `token_price` | number | Price of the token being borrowed |
| `symbol` | string | Symbol of the token being borrowed |
| `blockchain` | string | Ethereum or Polygon (presently only Ethereum) |

View File

@ -0,0 +1,22 @@
# Deposits
Deposits exist within the `aave` schema, as `aave.deposits`
| Field | Type | Description |
| ----------------------- | --------- | -------------------------------------------------------------- |
| `tx_id` | string | Transaction ID for this supply |
| `block_id` | number | The block height this event was recorded at |
| `block_timestamp` | timestamp | UTC timestamp for this transaction |
| `aave_market` | address | Address of the AAVE market/underlying contract |
| `aave_token` | address | aToken address |
| `issued_tokens` | number | Amount of tokens issued for providing liquidity |
| `supplied_usd` | number | USD amount provided as liquidity (decimal adjusted) |
| `depositor_address` | address | Address of liquidity provider |
| `lending_pool_contract` | address | Address of the lending pool contract used for this transaction |
| `aave_version` | string | AAVE version (V1, V2, or AMM for Ethereum) |
| `token_price` | number | Current price of the market token |
| `symbol` | string | Symbol of the market asset |
| `blockchain` | string | Ethereum or Polygon (presently only Ethereum) |

View File

@ -0,0 +1,28 @@
# Flashloans
Flashloans exist within the `aave` schema, as `aave.flashloans`
| Field | Type | Description |
| ----------------------- | --------- | --------------------------------------------- |
| `tx_id` | string | Transaction ID for this liquidation |
| `block_id` | number | The block height this event was recorded at |
| `block_timestamp` | timestamp | UTC timestamp for this transaction |
| `event_index` | number | Index of this event within the transaction |
| `aave_market` | address | Address of the token |
| `aave_token` | address | Address of the aToken |
| `flashloan_amount` | number | Amount of tokens borrowed |
| `flashloan_amount_usd` | number | USD amount borrowed |
| `premium_amount` | number | Premium paid on the loan |
| `premium_amount_usd` | number | USD premium paid on the loan |
| `initiator_address` | address | Address of the initiator of the loan |
| `target_address` | address | Address of the target of the loan |
| `lending_pool_contract` | address | Address of the lending pool contract |
| `aave_version` | string | AAVE version (V1, V2, or AMM for Ethereum) |
| `token_price` | number | Price of the token being borrowed |
| `symbol` | string | Symbol of the token being borrowed |
| `blockchain` | string | Ethereum or Polygon (presently only Ethereum) |

View File

@ -0,0 +1,29 @@
# Liquidations
Liquidations exist within the `aave` schema, as `aave.liquidations`
| Field | Type | Description |
| -------------------------- | --------- | --------------------------------------------- |
| `tx_id` | string | Transaction ID for this liquidation |
| `block_id` | number | The block height this event was recorded at |
| `block_timestamp` | timestamp | UTC timestamp for this transaction |
| `event_index` | number | Index of this event within the transaction |
| `collateral_asset` | address | Address of the collateral asset |
| `collateral_aave_token` | address | Address of the collateral aToken |
| `liquidated_amount` | number | Amount liquidated (decimal adjusted) |
| `liquidated_amount_usd` | number | USD amount liquidated (decimal adjusted) |
| `debt_asset` | address | Address of the debt asset |
| `debt_aave_token` | address | Address of the debt aToken |
| `debt_to_cover_amount` | number | Amount of debt to cover |
| `debt_to_cover_amount_usd` | number | USD amount of debt to cover |
| `liquidator` | address | Address of the liquidator |
| `borrower` | address | Address of the borrower |
| `aave_version` | string | AAVE version (V1, V2, or AMM for Ethereum) |
| `collateral_token_price` | number | Price of the collateral token |
| `collateral_token_symbol` | string | Symbol of the collateral token |
| `debt_token_price` | number | Price of the debt token |
| `debt_token_symbol` | string | Symbol of the debt token |
| `blockchain` | string | Ethereum or Polygon (presently only Ethereum) |

View File

@ -0,0 +1,36 @@
# Market Stats
Market Stats exists within the `aave` schema, as `aave.market_stats`
| **Field** | **Type** | Description |
| -------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `block_hour` | string | Market stats are aggregated by hour in UTC. `date_trunc(hour,block_timestamp)` for joins on other tables |
| `lending_pool_add` | string | Lending pool contract associated with the AAVE market (used for interacting with on-chain) |
| `data_provider` | string | Data Provider contract associated with the AAVE market (used for interacting with on-chain) |
| `reserve_name` | string | Name/symbol of the underlying contract (i.e. USDT) |
| `atoken_address` | address | Address of the atoken the market serves (i.e. aUSDC). Given to suppliers proportional to how much they supply to this market |
| `stable_debt_token_address` | address | Address of the stable debt token the market serves. Given to borrowers proportional to how much debt of this type from this market they hold |
| `variable_debt_token_address` | address | Address of the variable debt token the market serves. Given to borrowers proportional to how much debt of this type from this market they hold |
| `underlying_contract` | address | Address of the underlying contract, i.e. USDC's address |
| `reserve_price` | number | Price of the underlying token contract |
| `atoken_price` | number | Price of the aToken the market uses |
| `total_liquidity_token` | number | Total liquidity/total supplied. Includes amounts currently out on loans |
| `total_liquidity_usd` | number | Total liquidity converted to USD values as of the hour recorded |
| `total_stable_debt_token` | number | Total debt out at a stable borrow rate from this market |
| `total_stable_debt_usd` | number | Total Stable Debt converted to USD values as of the hour recorded |
| `total_variable_debt_token` | number | Total debt out at a variable borrow rate from this market |
| `total_variable_debt_usd` | number | Total Variable Debt converted to USD values as of the hour recorded |
| `utilization_rate` | number | The percentage of the reserves total capital which is borrowed at any given time, calculated as total borrows divided by total liquidity |
| `supply_rate` | number | The supplier's APY. It depends on the current 'utilization rate', the proportion borrowed from/supplied to the market. |
| `borrow_rate_stable` | number | The borrower's stable APY. It depends on the current 'utilization rate', the proportion borrowed from/supplied to the market. |
| `borrow_rate_variable` | number | The borrower's variable APY. It depends on the current 'utilization rate', the proportion borrowed from/supplied to the market. |
| `aave_price` | number | The current price of the AAVE governance token |
| `aave_version` | string | The version of the AAVE market (can be V1, V2 or AMM for Ethereum) |
| `blockchain` | string | Ethereum or Polygon (presently only Ethereum) |
| `stkaave_rate_supply`\* | number | The APR for liquidity mining distributions. Calculated as pool emissions per second times seconds per year times AAVE price divided by total pool liquidity. |
| `stkaave_rate_variable_borrow`\* | number | The APR for liquidity mining distributions. Calculated as pool emissions per second times seconds per year times AAVE price divided by total pool liquidity. |
\*AAVE price and total pool liquidity values used are USD equivalents instead of ETH, and therefore some small differences may exist vs. current rates on AAVE v2.

View File

@ -0,0 +1,19 @@
# Proposals
Votes exists within the `aave` schema, as `aave.proposals`
| **Field** | **Type** | Description |
| --------------------- | -------- | ---------------------------------------------------------------------------- |
| `block_id` | number | Block number in which the proposal was created |
| `start_voting_period` | number | Block number in which voting may start |
| `end_voting_period` | number | Block number in which voting must conclude |
| `block_timestamp` | string | Timestamp of the proposal's creation |
| `governance_contract` | address | Governance contract used in this vote |
| `proposal_id` | number | ID of the proposal, which can be used to join in votes from the voting table |
| `status` | string | Current status of the proposal -- Created, Queued, Executed or Failed |
| `targets` | array | Markets that are the target of the vote |
| `proposer` | address | Address of the user which issued the proposal |
| `proposal_tx` | string | Transaction of the initial proposal creation |
| `blockchain` | string | Ethereum or Polygon (presently only Ethereum) |

View File

@ -0,0 +1,26 @@
# Repayments
Repayments exist within the `aave` schema, as `aave.repayments`
| Field | Type | Description |
| ----------------------- | --------- | --------------------------------------------- |
| `tx_id` | string | Transaction ID for this liquidation |
| `block_id` | number | The block height this event was recorded at |
| `block_timestamp` | timestamp | UTC timestamp for this transaction |
| `event_index` | number | Index of this event within the transaction |
| `aave_market` | address | Address of the token |
| `aave_token` | address | Address of the aToken |
| `repayed_tokens` | number | Amount of tokens repayed |
| `repayed_usd` | number | USD amount repayed |
| `payer` | address | Address of the payer |
| `borrower` | address | Address of the borrower |
| `lending_pool_contract` | address | Address of the lending pool contract |
| `aave_version` | string | AAVE version (V1, V2, or AMM for Ethereum) |
| `token_price` | number | Price of the token being borrowed |
| `symbol` | string | Symbol of the token being borrowed |
| `blockchain` | string | Ethereum or Polygon (presently only Ethereum) |

View File

@ -0,0 +1,16 @@
# Votes
Votes exists within the `aave` schema, as `aave.votes`
| **Field** | **Type** | Description |
| --------------------- | -------- | ---------------------------------------------------------------------------- |
| `block_timestamp` | string | Block timestamp of the vote |
| `governance_contract` | address | Governance contract used in this vote |
| `proposal_id` | number | ID of the proposal, which can be used to join in votes from the voting table |
| `support` | string | Does the voter support the proposal? True/False |
| `voting_power` | number | Voting power, which depends on the voter's AAVE and stkAAVE balances |
| `voter` | address | voter's address |
| `tx_id` | string | Transaction of the vote |
| `blockchain` | string | Ethereum or Polygon (presently only Ethereum) |

View File

@ -0,0 +1,24 @@
# Withdraws
Withdraws exist within the `aave` schema, as `aave.withdraws`
| Field | Type | Description |
| ------------------- | --------- | --------------------------------------------- |
| `tx_id` | string | Transaction ID for this liquidation |
| `block_id` | number | The block height this event was recorded at |
| `block_timestamp` | timestamp | UTC timestamp for this transaction |
| `event_index` | number | Index of this event within the transaction |
| `aave_market` | address | Address of the token |
| `aave_token` | address | Address of the aToken |
| `withdrawn_tokens` | number | Amount of tokens withdrawn |
| `withdrawn_usd` | number | USD amount withdrawn |
| `depositor_address` | address | Address of the depositor |
| `aave_version` | string | AAVE version (V1, V2, or AMM for Ethereum) |
| `token_price` | number | Price of the token being borrowed |
| `symbol` | string | Symbol of the token being borrowed |
| `blockchain` | string | Ethereum or Polygon (presently only Ethereum) |

View File

@ -0,0 +1,12 @@
# Algorand Tables
The Algorand tables schema are based on the [Algorand indexer](https://github.com/algorand/indexer/releases/tag/2.8.0). Algorand tables are available in Velocity as the `algorand` schema. The tables are built based on the algorand asset, app, account, block, and transaction information.
At Flipside, we currently offer raw tables based on the Algorand indexer with the exception of transactions broken into separate tables based on transaction type. Click the following link to learn more about the tables. We will be continuing to add further curated tables of Algorand data so check back intermittently to learn about the additional tables that have been added.
Check out [the complete docs for our Algorand Base Tables](algorand-base-tables/) or watch this video overview:
{% embed url="https://www.youtube.com/watch?v=WOsrxrcdy88" %}

View File

@ -0,0 +1,3 @@
# Algorand Base Tables
The Algorand base tables contains data directly from the Algorand indexer with the exception of the transaction tables which are broken out into the different types of transactions that can be performed on the Algorand blockchain.

View File

@ -0,0 +1,14 @@
# Account App
The account app table contains all apps within the Algorand Ecosystem and an app ID and other information about the app, such as whether it's currently active.
## Table Schema
| Field | Type | Description |
| ------------ | ------- | -------------------------------------------------------------------------------------------- |
| `ADDRESS` | text | Wallet address tied to app |
| `APP_ID` | number | App ID, tied to index in the app table |
| `APP_CLOSED` | boolean | Has this app been deleted? |
| `CLOSED_AT` | number | block that the account\_app was last removed from the account |
| `CREATED_AT` | number | block that the app was added to an account |
| `APP_INFO` | array | Is the app currently deleted from the account? if not it will have json about current status |

View File

@ -0,0 +1,16 @@
# Account Asset
The account asset table is contains a current list of all the address that hold the existing assets on the algorand network.
## Table Schema
| field | Type | Description |
| -------------------- | ------- | ------------------------------------------------------ |
| `ADDRESS` | text | Wallet Address that is holding the asset |
| `ASSET_ID` | number | Asset ID, same as index identifier in asset table |
| `ASSET_NAME` | text | Name of the asset |
| `AMOUNT` | number | Amount of asset the wallet currently holds |
| `ASSET_ADDED_AT` | number | Block that the asset was added to an account |
| `ASSET_LAST_REMOVED` | number | block that the asset was last removed from the account |
| `ASSET_CLOSED` | boolean | whether or not the asset is currently deleted |
| `FROZEN` | boolean | whether or not the holding is frozen. |

View File

@ -0,0 +1,18 @@
# Account
The account table contains all address within the Algorand Ecosystem.
## Table Schema
****
| Field | Type | Description |
| ---------------- | ------ | ---------------------------------------------------------------------------------------------- |
| `ADDRESS` | text | The account public key |
| `ACCOUNT_CLOSED` | number | Whether or not the account is currently closed |
| `REWARDSBASE` | number | Used as part of the rewards computation. Only applicable to accounts which are participating. |
| `BALANCE` | number | Total number of ALGOs in the account |
| `CLOSED_AT` | number | Block during which this account was most recently closed |
| `CREATED_AT` | number | Block which account was created |
| `WALLET_TYPE` | text | Wallet type: sig(single signature), msig(multi-signature), lsig(programmatic-signature) |
| `ACCOUNT_DATA` | array | Optional Account data |

View File

@ -0,0 +1,15 @@
# App
The app table is contains a current list of all the apps with their app\_id and current status.
## Table Schema
| Field | Type | Description |
| ----------------- | ------- | ------------------------------------------- |
| `APP_ID` | number | App ID |
| `CREATOR_ADDRESS` | text | wallet creator account address |
| `APP_CLOSED` | boolean | whether or not the app is currently deleted |
| `CLOSED_AT` | number | block that the app was deleted |
| `CREATED_AT` | number | block that the app was created |
| `PARAMS` | array | |

View File

@ -0,0 +1,24 @@
# Application Call Transaction
This is a table for all transactions whose type is application call transactions. For more details on application call transactions. Visit here: [https://developer.algorand.org/docs/get-details/transactions/transactions/#application-call-transaction](https://developer.algorand.org/docs/get-details/transactions/transactions/#application-call-transaction)&#x20;
## Table Schema
All transactions have a distinct intra and block\_id combination. The intra is the transaction # into the block where the transaction was confirmed. Inner transactions(flagged with the inner tx flag) share the tx id of their parent application transactions so you can tie inner transaction to a parent transaction via a tx id. The inner transactions are seen as distinct transactions on the Algorand blockchain, which is signified by their intra and block id combination. One other note on the parent transactions, the parent transaction of inner transaction do not summarize the inner transactions and are seen as their own distinct transaction, which is usually an application call transaction.&#x20;
| Field | Type | Description |
| -------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `INTRA` | number | Transaction # into the block where this transaction was confirmed. |
| `BLOCK_ID` | number | Block in which the transaction was confirmed |
| `TX_GROUP_ID` | text | Transaction group ID, can be NULL. Exists when a group of transactions are tied together |
| `TX_ID` | text | The ID of this transaction |
| `INNER_TX` | boolean | A boolean true or false on whether or not this transaction has a parent transaction. The TX\_ID will be the same as the parent transaction but will have it's own intra. |
| `SENDER` | text | The address of the creator of this transaction |
| `FEE` | number | Fee associated with the transaction, in ALGOs |
| `APP_ID` | number | App ID associated with this application call transaction |
| `TX_TYPE` | number | Number associated with transaction type |
| `TX_TYPE_NAME` | text | transaction type name |
| `GENISIS_HASH` | text | The hash of the genesis block of the network for which the transaction is valid |
| `TX_MESSAGE` | array | Encoded JSON message associated with the transaction |
| `EXTRA` | array | Extra json associated with transaction |

View File

@ -0,0 +1,25 @@
# Asset Configuration Transaction
This is a table for all transactions whose type is Asset Configuration. These transactions are to create, configure and destroy an asset depending on which fields are set. For more details on asset configuration transactions. Visit here: [ ](https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-configuration-transaction)[https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-configuration-transaction](https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-configuration-transaction)
## Table Schema
All transactions have a distinct intra and block\_id combination. The intra is the transaction # into the block where the transaction was confirmed. Inner transactions(flagged with the inner tx flag) share the tx id of their parent application transactions so you can tie inner transaction to a parent transaction via a tx id. The inner transactions are seen as distinct transactions on the Algorand blockchain, which is signified by their intra and block id combination. One other note on the parent transactions, the parent transaction of inner transaction do not summarize the inner transactions and are seen as their own distinct transaction, which is usually an application call transaction.&#x20;
| Field | Type | Description |
| ------------------ | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `INTRA` | number | Transaction # into the block where this transaction was confirmed. |
| `BLOCK_ID` | number | Block the transaction was confirmed |
| `TX_GROUP_ID` | text | Transaction group ID, can be NULL. Exists when a group of transactions are tied together |
| `TX_ID` | text | Transaction ID of the transaction |
| `INNER_TX` | boolean | A boolean true or false on whether or not this transaction has a parent transaction. The TX\_ID will be the same as the parent transaction but will have it's own intra. |
| `ASSET_ID` | number | ID of Asset involved in the transaction |
| `ASSET_SUPPLY` | number | The total number of base units of the asset to create. This number cannot be changed. |
| `SENDER` | text | Address of the wallet creating the transaction |
| `FEE` | number | Fee associated with the transaction, in ALGOs |
| `ASSET_PARAMETERS` | array | All parameters involved with the asset being created, modified or destroyed in the transaction[https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-parameters](https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-parameters) |
| `TX_TYPE` | number | Number associated with transaction type |
| `TX_TYPE_NAME` | text | transaction type name |
| `GENISIS_HASH` | text | The hash of the genesis block of the network for which the transaction is valid |
| `TX_MESSAGE` | array | Encoded JSON message associated with the transaction |
| `EXTRA` | array | Extra json associated with transaction |

View File

@ -0,0 +1,25 @@
# Asset Freeze Transaction
This is a table for all transactions whose type is Asset Freeze. As the name implies these transactions are made to freeze transactions. Visit here: [ ](https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-configuration-transaction)[https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-freeze-transaction](https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-freeze-transaction)
## Table Schema
All transactions have a distinct intra and block\_id combination. The intra is the transaction # into the block where the transaction was confirmed. Inner transactions(flagged with the inner tx flag) share the tx id of their parent application transactions so you can tie inner transaction to a parent transaction via a tx id. The inner transactions are seen as distinct transactions on the Algorand blockchain, which is signified by their intra and block id combination. One other note on the parent transactions, the parent transaction of inner transaction do not summarize the inner transactions and are seen as their own distinct transaction, which is usually an application call transaction.&#x20;
| Field | Type | Description |
| --------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `INTRA` | number | Transaction # into the block where this transaction was confirmed. |
| `BLOCK_ID` | number | Block the transaction was confirmed |
| `TX_GROUP_ID` | text | Transaction group ID, can be NULL. Exists when a group of transactions are tied together |
| `TX_ID` | text | Transaction ID of the transaction |
| `INNER_TX` | boolean | A boolean true or false on whether or not this transaction has a parent transaction. The TX\_ID will be the same as the parent transaction but will have it's own intra. |
| `ASSET_ID` | number | The asset ID being frozen or unfrozen. |
| `ASSET_ADDRESS` | text | The address of the account whose asset is being frozen or unfrozen. |
| `ASSET_FREEZE` | boolean | True to freeze the asset, otherwise null or false |
| `SENDER` | text | Address of the wallet creating the transaction |
| `FEE` | number | Fee associated with the transaction, in ALGOs |
| `TX_TYPE` | number | Number associated with transaction type |
| `TX_TYPE_NAME` | text | transaction type name |
| `GENISIS_HASH` | text | The hash of the genesis block of the network for which the transaction is valid |
| `TX_MESSAGE` | array | Encoded JSON message associated with the transaction |
| `EXTRA` | array | Extra json associated with transaction |

View File

@ -0,0 +1,27 @@
# Asset Transfer Transaction
This is a table for all transactions whose type is Asset Transfer. This is when an asset is transferred from one wallet to another. Visit here for more details: [ ](https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-configuration-transaction)[https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-transfer-transaction](https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-transfer-transaction)
## Table Schema
All transactions have a distinct intra and block\_id combination. The intra is the transaction # into the block where the transaction was confirmed. Inner transactions(flagged with the inner tx flag) share the tx id of their parent application transactions so you can tie inner transaction to a parent transaction via a tx id. The inner transactions are seen as distinct transactions on the Algorand blockchain, which is signified by their intra and block id combination. One other note on the parent transactions, the parent transaction of inner transaction do not summarize the inner transactions and are seen as their own distinct transaction, which is usually an application call transaction.&#x20;
| Field | Type | Description |
| ------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `INTRA` | number | Transaction # into the block where this transaction was confirmed. |
| `BLOCK_ID` | number | Block the transaction was confirmed |
| `TX_GROUP_ID` | text | Transaction group ID, can be NULL. Exists when a group of transactions are tied together |
| `TX_ID` | text | Transaction ID of the transaction |
| `INNER_TX` | boolean | A boolean true or false on whether or not this transaction has a parent transaction. The TX\_ID will be the same as the parent transaction but will have it's own intra. |
| `ASSET_ID` | number | The asset ID of the asset being transferred |
| `SENDER` | text | Address of the wallet creating the transaction |
| `FEE` | number | Fee associated with the transaction, in ALGOs |
| `ASSET_SENDER` | text | The sender of the transfer. The regular [sender](https://developer.algorand.org/docs/get-details/transactions/transactions/#sender) field should be used and this one set to the zero value for regular transfers between accounts. If this value is nonzero, it indicates a clawback transaction where the [sender](https://developer.algorand.org/docs/get-details/transactions/transactions/#sender) is the asset's clawback address and the asset sender is the address from which the funds will be withdrawn. |
| `ASSET_RECEIVER` | text | The recipient of the asset transfer. |
| `ASSET_AMOUNT` | number | The amount of the asset to be transferred. A zero amount transferred to self allocates that asset in the account's Asset map. |
| `ASSET_TRANSFERRED` | number | The Asset ID of the asset transferred in the asset transfer transaction. |
| `TX_TYPE` | number | Number associated with transaction type |
| `TX_TYPE_NAME` | text | transaction type name |
| `GENISIS_HASH` | text | The hash of the genesis block of the network for which the transaction is valid |
| `TX_MESSAGE` | array | Encoded JSON message associated with the transaction |
| `EXTRA` | array | Extra json associated with transaction |

View File

@ -0,0 +1,17 @@
# Asset
The asset table is contains a current list of all the assets with their asset\_id, current status and other info.
## Table Schema
| Field | Type | Description |
| ----------------- | ------- | --------------------------------------------- |
| `ASSET_ID` | number | Asset ID |
| `CREATOR_ADDRESS` | text | Address of the asset creator |
| `TOTAL_SUPPLY` | number | Total supply of the asset |
| `ASSET_NAME` | text | Name of the asset |
| `ASSET_URL` | text | The url to the asset website |
| `DECIMALS` | number | Number of decimals this asset has |
| `ASSET_DELETED` | boolean | whether or not the asset is currently deleted |
| `CLOSED_AT` | number | block that the asset was closed |
| `CREATED_AT` | number | block that the asset was created |

View File

@ -0,0 +1,16 @@
# Block
This table displays block\_ids, rewards associated with a block, and the time a block was minted and confirmed. In the Algorand ecosystem a block is also known as a round.
## Table Schema
| Field | Type | Description |
| ----------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `BLOCK_ID` | number | The block |
| `BLOCK_TIMESTAMP` | timestamp | Timestamp of block minting(without a timezone) |
| `REWARDSLEVEL` | number | How many rewards, in MicroAlgos, have been distributed to each RewardUnit of MicroAlgos since genesis. Link: https://algorand.github.io/java-algorand-sdk/com/algorand/algosdk/v2/client/model/BlockRewards.html |
| `NETWORK` | text | Signifying whether the block is from mainnet or testnet |
| `GENISIS_HASH` | text | ID to which this block belongs |
| `PREV_BLOCK_HASH` | number | ID to which the block before this belongs |
| `TXN_ROOT` | boolean | TransactionsRoot authenticates the set of transactions appearing in the block. More specifically, it's the root of a merkle tree whose leaves are the block's Txids, in lexicographic order. For the empty block, it's 0. Note that the TxnRoot does not authenticate the signatures on the transactions, only the transactions themselves. Two blocks with the same transactions but in a different order and with different signatures will have the same TxnRoot. |
| `HEADER` | array | Block details, see rules below- for more message details https://developer.algorand.org/docs/rest-apis/indexer/#blockrewards |

View File

@ -0,0 +1,13 @@
---
description: The end of day balance of ALGOs for an address.
---
# Daily Balances
| Field | Type | Description |
| --------- | ------- | ------------------------------------- |
| `DATE` | date | The date time for this balance record |
| `ADDRESS` | address | The balance address |
| `BALANCE` | number | The amount of the balance |

View File

@ -0,0 +1,28 @@
# Key Registration Transaction
This is a table for all transactions whose type is Key Registration. A key registration signifies whether or not a wallet is participating in rewards. To learn more about key registration transactions visit here: [https://developer.algorand.org/docs/get-details/transactions/transactions/#key-registration-transaction](https://developer.algorand.org/docs/get-details/transactions/transactions/#key-registration-transaction)
## Table Schema
All transactions have a distinct intra and block\_id combination. The intra is the transaction # into the block where the transaction was confirmed. Inner transactions(flagged with the inner tx flag) share the tx id of their parent application transactions so you can tie inner transaction to a parent transaction via a tx id. The inner transactions are seen as distinct transactions on the Algorand blockchain, which is signified by their intra and block id combination. One other note on the parent transactions, the parent transaction of inner transaction do not summarize the inner transactions and are seen as their own distinct transaction, which is usually an application call transaction.&#x20;
| Field | Type | Description |
| ------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `INTRA` | number | Transaction # into the block where this transaction was confirmed. |
| `BLOCK_ID` | number | Block the transaction was confirmed |
| `TX_GROUP_ID` | text | Transaction group ID, can be NULL. Exists when a group of transactions are tied together |
| `TX_ID` | text | Transaction ID of the transaction |
| `INNER_TX` | boolean | A boolean true or false on whether or not this transaction has a parent transaction. The TX\_ID will be the same as the parent transaction but will have it's own intra. |
| `ASSET_ID` | number | The asset ID of the asset associated with the key registration |
| `SENDER` | text | Address of the wallet creating the transaction |
| `FEE` | number | Fee associated with the transaction, in ALGOs |
| `PARTICIPATION_KEY` | text | The root participation public key. |
| `VRF_PUBLIC_KEY` | text | The VRF public key. |
| `VOTE_FIRST` | number | The first round that the participation key is valid. Not to be confused with the FirstValid round of the keyreg transaction. |
| `VOTE_LAST` | number | The last round that the participation key is valid. Not to be confused with the LastValid round of the keyreg transaction. |
| `VOTE_KEYDILUTION` | number | This is the dilution for the 2-level participation key. |
| `TX_TYPE` | number | Number associated with transaction type |
| `TX_TYPE_NAME` | text | transaction type name |
| `GENISIS_HASH` | text | The hash of the genesis block of the network for which the transaction is valid |
| `TX_MESSAGE` | array | Encoded JSON message associated with the transaction |
| `EXTRA` | array | Extra json associated with transaction |

View File

@ -0,0 +1,25 @@
# Payment Transaction
This is a table for all transactions whose type is Payment. This is when a user send a payment and can also be used to send the remainder of an account so it can be closed. To learn more visit: [https://developer.algorand.org/docs/get-details/transactions/transactions/#payment-transaction](https://developer.algorand.org/docs/get-details/transactions/transactions/#payment-transaction)
## Table Schema
All transactions have a distinct intra and block\_id combination. The intra is the transaction # into the block where the transaction was confirmed. Inner transactions(flagged with the inner tx flag) share the tx id of their parent application transactions so you can tie inner transaction to a parent transaction via a tx id. The inner transactions are seen as distinct transactions on the Algorand blockchain, which is signified by their intra and block id combination. One other note on the parent transactions, the parent transaction of inner transaction do not summarize the inner transactions and are seen as their own distinct transaction, which is usually an application call transaction.&#x20;
| Field | Type | Description |
| -------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `INTRA` | number | Transaction # into the block where this transaction was confirmed. |
| `BLOCK_ID` | number | Block the transaction was confirmed |
| `TX_GROUP_ID` | text | Transaction group ID, can be NULL. Exists when a group of transactions are tied together |
| `TX_ID` | text | Transaction ID of the transaction |
| `INNER_TX` | boolean | A boolean true or false on whether or not this transaction has a parent transaction. The TX\_ID will be the same as the parent transaction but will have it's own intra. |
| `ASSET_ID` | number | The asset ID of the asset being sent |
| `SENDER` | text | Address of the wallet creating the transaction |
| `RECEIVER` | text | Address of the wallet receiving the payment |
| `AMOUNT` | number | Amount of the asset being sent to the receiver |
| `FEE` | number | Fee associated with the transaction, in ALGOs |
| `TX_TYPE` | number | Number associated with transaction type |
| `TX_TYPE_NAME` | text | transaction type name |
| `GENISIS_HASH` | text | The hash of the genesis block of the network for which the transaction is valid |
| `TX_MESSAGE` | array | Encoded JSON message associated with the transaction |
| `EXTRA` | array | Extra json associated with transaction |

View File

@ -0,0 +1,14 @@
# Prices Pool Balances
This table can be used to price assets within the Algorand blockchain using on-chain liquidity pool. Price is calculated by end-of-hour pool balances on tinyman for Algo base pairs, then using the coinmarketcap/coingiecko ALGO price to calculate the price of the other asset
| Field | Type | Description |
| ------------------ | --------- | -------------------------------------------------------------------------------------------------- |
| BLOCK\_HOUR | timestamp | The hour for which the price is valid |
| ASSET\_ID | numeric | ID associated with the asset |
| ASSET\_NAME | string | Name of the asset |
| PRICE\_USD | numeric | The USD price of the asset at the end of the hour. ALGO price pulled from coinmarketcap/coingiecko |
| ALGO\_BALANCE | numeric | The balance of ALGO tokens in the pool at the end of the hour. NULL for ALGO |
| NON\_ALGO\_BALANCE | numeric | The balance of other (non-ALGO) tokens in the pool at the end of the hour. NULL for ALGO |
| POOL\_NAME | string | The name of the pool used for the price calculation. NULL for ALGO |
| POOL\_ADDRESS | string | The address of the pool used for the price calculation. NULL for ALGO |

View File

@ -0,0 +1,17 @@
# Prices Swap
This table can be used to price assets within the Algorand blockchain using on-chain swaps. Price is calculated by using all swaps within two standard deviations from the hour average price, calculating the average price at the dex level, then weighting the dex price by the previous day's volume to create a weighted average across all dexes.
| Field | Type | Description |
| --------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| BLOCK\_HOUR | timestamp | The hour for which the price is valid |
| ASSET\_ID | numeric | ID associated with the asset |
| ASSET\_NAME | string | Name of the asset |
| PRICE\_USD | numeric | This table can be used to price assets within the Algorand blockchain using on-chain swaps. Price is calculated by using all swaps within two standard deviations from the hour average price, calculating the average price at the dex level, then weighting the dex price by the previous day's volume to create a weighted average across all dexes. |
| MIN\_PRICE\_USD\_HOUR | numeric | The lowest price found in a swap in the hour in USD |
| MAX\_PRICE\_USD\_HOUR | numeric | The highest price found in a swap in the hour in USD |
| VOLATILITY\_MEASURE | numeric | The difference between the min and max price for the hour |
| SWAPS\_IN\_HOUR | integer | The number of swap transactions in the hour that involved this asset |
| VOLUME\_USD\_IN\_HOUR | numeric | The volume of swap transactions (in USD) in the hour for this asset |

View File

@ -0,0 +1,19 @@
# Swaps
The swaps table compiles the swaps from the DEXes(decentralized exchanges) throughout the Algorand ecosystem. This table includes the Tinyman, AlgoFi, PactFi, and Wagmiswap DEX. \
\
**Important Note**: When looking at volume we will look at all rows for swaps. However, when looking at the number of swaps we should only count the number of swaps where swaps have a swap\_from_\__amount > 0. This is due to slippage payouts where a users signs an additional swap transaction to receive additional asset due to a change in price during the swap.\
| Field | Type | Description |
| ----------------------- | --------- | ---------------------------------------------------------- |
| swap\_program | string | The DEX or program used to make the swap |
| block\_timestamp | timestamp | The time the block began |
| block\_id | integer | Unique sequential number that identifies the current block |
| tx\_id | string | A unique key that identifies a transaction |
| swapper | string | Address that initiated the swap |
| swap\_from_\__amount | integer | Total amount of the token sent in to initiate the swap |
| swap\__from\_asset\_id_ | string | Token being sent or swapped from |
| pool\_address | string | Address of the pool the swap is coming from |
| swap\_to_\__amount | integer | Total amount of the token received in the swap |
| swap\_to_\_asset\_id_ | string | Token being received or swapped for |

View File

@ -0,0 +1,12 @@
# Transactions Participation
This is a transaction participation table which lists the addresses involved in a transaction within a block and what intra the address was involved in.
## Table Schema
| Field | Type | Description |
| ---------- | ------ | ---------------------------------------------------------- |
| `INTRA` | number | Offset into the block where this transaction was confirmed |
| `BLOCK_ID` | number | Block |
| `ADDRESS` | text | Wallet address associated with intra and block |

View File

@ -0,0 +1,25 @@
# Transactions
This is a table that includes and transactions andout transactions on the Algorand network, visit here: [https://developer.algorand.org/docs/get-details/transactions/transactions/#common-fields-header-and-type](https://developer.algorand.org/docs/get-details/transactions/transactions/#common-fields-header-and-type) .&#x20;
## Table Schema
The structure of all transaction tables follow the structure of the overarching transaction table. Each transaction table besides the overarching transaction table are a collection of all the transaction of one of the 6 types. \
All transactions have a distinct intra and block\_id combination. The intra is the transaction # into the block where the transaction was confirmed. Inner transactions(flagged with the inner tx flag) share the tx id of their parent application transactions so you can tie inner transaction to a parent transaction via a tx id. The inner transactions are seen as distinct transactions on the Algorand blockchain, which is signified by their intra and block id combination. One other note on the parent transactions, the parent transaction of inner transaction do not summarize the inner transactions and are seen as their own distinct transaction, which is usually an application call transaction.&#x20;
| Field | Type | Description |
| ----------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `BLOCK_TIMESTAMP` | datetime | Timestamp of block minting(without a timezone) |
| `INTRA` | number | Transaction # into the block where this transaction was confirmed. |
| `BLOCK_ID` | number | Block the transaction was confirmed |
| `TX_GROUP_ID` | text | Transaction group ID, can be NULL. Exists when a group of transactions are tied together for things like a dex swap. |
| `TX_ID` | text | Transaction ID of the transaction |
| INNER\_TX | boolean | A boolean true or false on whether or not this transaction has a parent transaction. The TX\_ID will be the same as the parent transaction but will have it's own intra. |
| `ASSET_ID` | number | The asset ID of the asset involved in the transaction. (This will be null for Application call transactions.) |
| `SENDER` | text | Address of the wallet creating the transaction |
| `FEE` | number | Fee associated with the transaction, in ALGOs |
| `TX_TYPE` | number | Number associated with transaction type |
| `TX_TYPE_NAME` | text | transaction type name |
| `GENISIS_HASH` | text | The hash of the genesis block of the network for which the transaction is valid |
| `TX_MESSAGE` | array | Encoded JSON message associated with the transaction |
| `EXTRA` | array | Extra json associated with transaction |

View File

@ -0,0 +1,32 @@
# Transfers
This tables aims to simply the Algorand tables by combining the Payment Transaction Table and the Asset Transfer Transaction table and decimal adjusting all amounts from both of these tables.&#x20;
This means both payment transaction("pay") and asset transfer transaction("axfer") types will be included in the table. While the payment table was previously decimal adjusted we are now decimal adjusting all amounts for assets out side of ALGO(asset\_id = 0) as well.&#x20;
We have also broken out sender into **asset\_sender** which is the wallet from which the asset is sent from and **tx\_sender** which is the wallet which initiates the transaction. 99% of transactions these values are the same - however, this now gives us an easier way to look at clawback transactions([https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-transfer-transaction](https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-transfer-transaction)) which are detailed here. For most purposes we can use **asset\_sender** unless we want to look asset clawback transactions for the asset transfer transactions.
## Table Schema
All transactions have a distinct intra and block\_id combination. The intra is the transaction # into the block where the transaction was confirmed. Inner transactions(flagged with the inner tx flag) share the tx id of their parent application transactions so you can tie inner transaction to a parent transaction via a tx id. The inner transactions are seen as distinct transactions on the Algorand blockchain, which is signified by their intra and block id combination.
| Field | Type | Description |
| ------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `BLOCK_TIMESTAMP` | datetime | Timestamp of block minting(without a timezone) |
| `INTRA` | number | Transaction # into the block where this transaction was confirmed |
| `BLOCK_ID` | number | Block the transaction was confirmed |
| `TX_GROUP_ID` | text | Transaction group ID, can be NULL. Exists when a group of transactions are tied together |
| `TX_ID` | text | An identifier tied to a transaction and its inner transactions. |
| `INNER_TX` | boolean | A boolean true or false on whether or not this transaction has a parent transaction. The TX\_ID will be the same as the parent transaction but will have it's own intra. |
| `ASSET_SENDER` | text | The wallet address from which the asset is transferred from. This can be different from the asset\_sender if a wallet has opted in to allow another address to send an asset from its wallet(https://developer.algorand.org/docs/get-details/transactions/transactions/#asset-transfer-transaction). |
| `TX_SENDER` | text | The wallet address from which the transaction is initiated from and pays the fee. The tx\_sender can send assets from a different asset\_sender address if the asset\_sender has opted into this action. This relates to clawback transactions: see asset\_sender for more details. |
| `RECEIVER` | text | The recipient of the transfer. |
| `ASSET_ID` | number | ID associated with the asset |
| `AMOUNT` | number | The amount of the asset to be transferred. Can be 0. |
| `FEE` | number | Fee associated with the transaction, in ALGOs |
| `ASSET_TRANSFERRED` | number | The Asset ID of the asset transferred in the asset transfer transaction. |
| `TX_TYPE` | number | Number associated with transaction type |
| `TX_TYPE_NAME` | text | transaction type name |
| `GENISIS_HASH` | text | The hash of the genesis block of the network for which the transaction is valid |
| `TX_MESSAGE` | array | Encoded JSON message associated with the transaction |
| `EXTRA` | array | Extra json associated with transaction |

View File

@ -0,0 +1,25 @@
# Arbitrum Tables
Documentation for \`arbitrum\` tables can be found [here](https://flipsidecrypto.github.io/arbitrum-models/#!/overview).
Please note, data is in 'lite mode' - meaning, historical data has not yet been backfilled. Please see the `min(block`\_`timestamp)`.&#x20;
Quick Links to Table Docs:
* ``[`fact_event_logs`](https://flipsidecrypto.github.io/arbitrum-models/#!/model/model.arbitrum\_models.core\_\_fact\_event\_logs)``
* ``[`fact_transactions`](https://flipsidecrypto.github.io/arbitrum-models/#!/model/model.arbitrum\_models.core\_\_fact\_transactions)``
* ``[`fact_blocks`](https://flipsidecrypto.github.io/arbitrum-models/#!/model/model.arbitrum\_models.core\_\_fact\_blocks)``
* ``[`fact_traces`](https://flipsidecrypto.github.io/arbitrum-models/#!/model/model.arbitrum\_models.core\_\_fact\_traces)``
* ``[`fact_token_transfers`](https://flipsidecrypto.github.io/arbitrum-models/#!/model/model.arbitrum\_models.core\_\_fact\_token\_transfers)``
* ``[`dim_labels`](https://flipsidecrypto.github.io/arbitrum-models/#!/model/model.arbitrum\_models.core\_\_dim\_labels)``
* ``[`ez_eth_transfers`](https://flipsidecrypto.github.io/arbitrum-models/#!/model/model.arbitrum\_models.core\_\_ez\_eth\_transfers)``
``
Arbitrum sushi tables
* [sushi\_\__dim\_dex\__pools](https://cloud.getdbt.com/accounts/1258/runs/68372630/docs/#!/model/model.arbitrum\_models.sushi\_\_dim\_dex\_pools)
* [sush\_\__dim\_kashi\_pairs_ ](https://cloud.getdbt.com/accounts/1258/runs/68372630/docs/#!/model/model.arbitrum\_models.sushi\_\_dim\_kashi\_pairs)__
* __[_sushi\_\_ez\_swaps_](https://cloud.getdbt.com/accounts/1258/runs/68372630/docs/#!/model/model.arbitrum\_models.sushi\_\_ez\_swaps)__
* __[_sushi\_\_ez\_borrowing_](https://flipsidecrypto.github.io/arbitrum-models/#!/model/model.arbitrum\_models.sushi\_\_ez\_borrowing)__
* __[_sushi\_\_ez\_lending_](https://flipsidecrypto.github.io/arbitrum-models/#!/model/model.arbitrum\_models.sushi\_\_ez\_lending)__

View File

@ -0,0 +1,6 @@
# Astroport Tables
Astroport is an automated market-maker (AMM) protocol on the Terra blockchain.&#x20;
From [Astroport's docs](https://docs.astroport.fi/astroport/astroport-onboarding/the-impact) : "Astroport is a next-generation AMM for Terra that was built to improve pricing and trade efficiency. Better pricing and efficiency should help Astroport attract more liquidity, further improving pricing and efficiency in a self-reinforcing loop. That is key, as trade efficiency is what ultimately drives adoption and integration with other protocols."

View File

@ -0,0 +1,20 @@
---
description: astroport.pool_reserves
---
# Astroport Pool Reserves
This table provides block by block pool reserve information including total pool shares, pool currencies, and token amounts in Astroport pools.&#x20;
| Field | Type | Description |
| ------------------ | --------- | ------------------------------------------------------------------------------------ |
| `blockchain` | text | The blockchain this pool was created on. |
| `chain_id` | text | ID of blockchain to connect to, it can be _columbus-3, columbus-4, columbus-5, etc._ |
| `block_id` | number | The block number that this pool reserve was recorded |
| `block_timestamp` | timestamp | The block timestamp that this pool reserve was recorded |
| `contract_address` | address | The address of the liquidity pool |
| `total_share` | number | The total amount of shares in a pool |
| `token_0_currency` | text | Token 0 currency |
| `token_0_amount` | number | Token 0 amount in pool |
| `token_1_currency` | text | Token 1 currency |
| `token_1_amount` | number | Token 1 amount in pool |

View File

@ -0,0 +1,32 @@
---
description: astroport.swaps
---
# Astroport Swaps
This swaps table contains the information for swap behavior, it involves the sender (trader) and the liquidity pool where the swap takes place.&#x20;
## Table Schema
****
| Field | Type | Description |
| ------------------- | --------- | ------------------------------------------------------------------------------------ |
| `BLOCKCHAIN` | text | The blockchain this swap was created on (Terra) |
| `CHAIN_ID` | text | ID of blockchain to connect to, it can be _columbus-3, columbus-4, columbus-5, etc._ |
| `BLOCK_ID` | number | The block number that this swap was recorded |
| `MSG_INDEX` | number | The message index for this swap |
| `TX_INDEX` | number | The transaction index for this swap, some transactions contain multiple swaps |
| `BLOCK_TIMESTAMP` | timestamp | The block timestamp that this swap was recorded |
| `TX_ID` | text | The transaction that contained this swap |
| `SENDER` | address | Sender (trader) address for this swap |
| `OFFER_AMOUNT` | number | Amount to offer for this swap |
| `OFFER_AMOUNT_USD` | number | USD Amount to offer for this swap |
| `OFFER_CURRENCY` | text | Currency to offer for this swap |
| `RETURN_AMOUNT` | number | Amount returned for this swap |
| `RETURN_AMOUNT_USD` | number | USD Amount returned for this swap |
| `RETURN_CURRENCY` | text | The currency returned for the swap |
| `POOL_ADDRESS` | text | The address for the pool where the currencies were swapped |
| `POOL_NAME` | text | The name of the pool where the currencies were swapped |

View File

@ -0,0 +1,25 @@
# Avalanche Tables
Documentation for \`avalanche\` tables can be found [here](https://flipsidecrypto.github.io/avalanche-models/#!/overview).
Please note, data is in 'lite mode' - meaning, historical data has not yet been backfilled. Please see the `min(block`\_`timestamp)`.&#x20;
Quick Links to Table Docs:
* ``[`fact_event_logs`](https://flipsidecrypto.github.io/avalanche-models/#!/model/model.avalanche\_models.core\_\_fact\_event\_logs)``
* ``[`fact_transactions`](https://flipsidecrypto.github.io/avalanche-models/#!/model/model.avalanche\_models.core\_\_fact\_transactions)``
* ``[`fact_blocks`](https://flipsidecrypto.github.io/avalanche-models/#!/model/model.avalanche\_models.core\_\_fact\_blocks)``
* ``[`fact_traces`](https://flipsidecrypto.github.io/avalanche-models/#!/model/model.avalanche\_models.core\_\_fact\_traces)``
* &#x20;[`fact_token_transfers`](https://flipsidecrypto.github.io/avalanche-models/#!/model/model.avalanche\_models.core\_\_fact\_token\_transfers)
* ``[`dim_labels`](https://flipsidecrypto.github.io/avalanche-models/#!/model/model.avalanche\_models.core\_\_dim\_labels)``
* ``[`ez_avax_transfers`](https://flipsidecrypto.github.io/avalanche-models/#!/model/model.avalanche\_models.core\_\_ez\_avax\_transfers)``
``
Arbitrum sushi tables
* [sushi\_\__dim\_dex\__pools](https://flipsidecrypto.github.io/avalanche-models/#!/model/model.avalanche\_models.sushi\_\_dim\_dex\_pools)
* [sushi\_\__dim\_kashi\_pairs_](https://flipsidecrypto.github.io/avalanche-models/#!/model/model.avalanche\_models.sushi\_\_dim\_kashi\_pairs)__
* __[_sushi\_\_ez\_swaps_](https://flipsidecrypto.github.io/avalanche-models/#!/model/model.avalanche\_models.sushi\_\_ez\_swaps)__
* __[_sushi\_\_ez\_borrowing_](https://flipsidecrypto.github.io/avalanche-models/#!/model/model.avalanche\_models.sushi\_\_ez\_borrowing)__
* __[_sushi\_\_ez\_lending_](https://flipsidecrypto.github.io/avalanche-models/#!/model/model.avalanche\_models.sushi\_\_ez\_lending)__

View File

@ -0,0 +1,23 @@
# BSC Tables
Documentation for \`bsc\` tables can be found [`here`](https://flipsidecrypto.github.io/bsc-models/#!/overview).
Please note, data is in 'lite mode' - meaning, historical data has not yet been backfilled. Please see the `min(block`\_`timestamp)`.&#x20;
Quick Links to Table Docs:
* ``[`fact_event_logs`](https://flipsidecrypto.github.io/bsc-models/#!/model/model.bsc\_models.core\_\_fact\_event\_logs)``
* ``[`fact_transactions`](https://flipsidecrypto.github.io/bsc-models/#!/model/model.bsc\_models.core\_\_fact\_transactions)``
* ``[`fact_blocks`](https://flipsidecrypto.github.io/bsc-models/#!/model/model.bsc\_models.core\_\_fact\_blocks)``
* ``[`fact_traces`](https://flipsidecrypto.github.io/bsc-models/#!/model/model.bsc\_models.core\_\_fact\_traces)``
* ``[`fact_token_transfers`](https://flipsidecrypto.github.io/bsc-models/#!/model/model.bsc\_models.core\_\_fact\_token\_transfers)``
* ``[`dim_labels`](https://flipsidecrypto.github.io/bsc-models/#!/model/model.bsc\_models.core\_\_dim\_labels)``
* ``[`ez_bnb_transfers`](https://flipsidecrypto.github.io/bsc-models/#!/model/model.bsc\_models.core\_\_ez\_bnb\_transfers)``
`Sushi`
* ``[`dim_dex_pools`](https://flipsidecrypto.github.io/bsc-models/#!/model/model.bsc\_models.sushi\_\_dim\_dex\_pools)``
* ``[`dim_kashi_pairs`](https://cloud.getdbt.com/accounts/1258/runs/77461492/docs/#!/model/model.bsc\_models.sushi\_\_dim\_kashi\_pairs)``
* ``[`ez_swaps`](https://flipsidecrypto.github.io/bsc-models/#!/model/model.bsc\_models.sushi\_\_ez\_swaps)``
* ``[`ez_borrowing`](https://cloud.getdbt.com/accounts/1258/runs/77461492/docs/#!/model/model.bsc\_models.sushi\_\_ez\_borrowing)``
* ``[`ez_lending`](https://cloud.getdbt.com/accounts/1258/runs/77461492/docs/#!/model/model.bsc\_models.sushi\_\_ez\_lending)``

View File

@ -0,0 +1,58 @@
# Compound Tables
**Blockchain:** [Ethereum](https://ethereum.org/en/)
The Compound table schemas build on the concepts laid out in [Flipside's event data model](../../data-models/events-data-model.md#event-model). Below is a visual overview of the Compound protocol's primary functions of decentralized borrowing and lending.&#x20;
![](<../../../.gitbook/assets/Screen Shot 2021-04-20 at 11.44.31 AM.png>)
We have tables for most major events within the Compound ecosystem, though the data is still early. The tables are intended to be as easy to work with as possible and paint as complete a picture of Compound as possible. Here are [sample Compound queries](https://velocity-app.flipsidecrypto.com/velocity/collections/d54dd195-163c-4153-8595-50b22f629b08).
**What we have:**&#x20;
* A table for summarizing major metrics by market: `compound.market_stats.` This table aggregates by the hour, and should have all available markets/cTokens listed here [https://compound.finance/markets](https://compound.finance/markets)
* Tables for key events for suppliers: `compound.redemptions` and `compound.deposits.` In the diagram above these events correspond to both interactions between suppliers and the lending markets.
* Tables for key events for borrowers: `compound.borrows`, `compound.repayments` and `compound.liquidations`. These correspond to the three interactions between lending markets, borrowers, and liquidators in the diagram above.
* The data goes back only as far as October 2020, with more to come.
**What we don't have:**
We did choose, for now to omit tables for governance actions, such as proposals and voting. This decision was mostly due to the very different levels of activity on the two sides. There is significantly greater activity centered around the markets and what seemed to be of the greatest interest to users. However, governance actions can still be parsed from `ethereum.events`.
**Feedback and Improvements:**
All feedback and criticism remain very much appreciated! Send a ping in [our discord](https://discord.gg/uW5jK2jRTg)! (@connorH) or send us an email at _hello@flipsidecrypto.com._
**General Tips**:
* &#x20;Using marketstats as a starting point is often an excellent idea, as it tends to connect to each of the other tables and is very centrally located. This table aggregates by hour, so join on `market_stats.date_trunc('hour',block_hour) = block_timestamp AND market_stats.ctoken_address = ctoken`
* As mentioned we only have data going back to October, but we are in the process of completing a backfill of our data!&#x20;
* Governance actions may not have their own tables but they are still available. If you find the appropriate event you can locate it within the table ethereum.events\_emitted . If you think you'd be using this routinely let us know, and we'll create more views for these events.
For instance new proposals to vote on are created using ProposalCreated, so you could list all created proposals with
```
SELECT
block_timestamp,
tx_id,
event_name,
CASE WHEN contract_address = '0xc0da01a04c3f3e0be433606045bb7017a7323e38' THEN 'Alpha' ELSE 'Bravo'
END AS governor_contract,
event_inputs:id AS proposal_id,
REGEXP_REPLACE(event_inputs:proposer,'\"','') AS proposer,
REGEXP_REPLACE(event_inputs:targets,'\"','') AS targets,
REGEXP_REPLACE(event_inputs:description,'\"','') AS description
FROM ethereum.events_emitted
WHERE
contract_address IN ('0xc0da01a04c3f3e0be433606045bb7017a7323e38', -- governance contracts
'0xc0da02939e1441f497fd74f78ce7decb17b66529')
AND
block_timestamp >= CURRENT_DATE - 120
AND event_name = 'ProposalCreated' -- the event
```
**Pro Tip for advanced users:**
* The documentation for compound combines excellently with the events\_emitted table. If you can find an event in the docs there, you can find it in the link below or [here](https://compound.finance/docs/ctokens#key-events)!&#x20;
&#x20; [https://compound.finance/docs/ctokens#key-events](https://compound.finance/docs/ctokens#key-events)

View File

@ -0,0 +1,17 @@
# Borrows
Borrows exist within the `compound` schema, as `compound.borrows`
| Field | Type | Description |
| -------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------- |
| `block_id` | number | The block height this event was recorded at |
| `block_timestamp` | timestamp | UTC block timestamp for parent block |
| `borrower` | address | Address that initiated a borrow event |
| `borrows_contract_address` | address | Address of borrowed token |
| `borrows_contract_symbol` | string | Symbol of borrowed token |
| `ctoken` | address | Respective cToken address to the borrowed token |
| `ctoken_symbol` | string | Respective cToken symbol to the borrowed token |
| `loan_amount` | number | Native amount of borrow (decimal adjusted) |
| `loan_amount_usd` | number | The equivalent borrow amount in USD. Note this is computed by taking the average hourly price around the time of the tx event |
| `tx_id` | string | Transaction id for this borrow |

View File

@ -0,0 +1,17 @@
# Liquidations
Liquidations exist within the `compound` schema, as `compound.liquidations`
| Field | Type | Description |
| ------------------------------ | --------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| `block_id` | number | The block height this event was recorded at. |
| `block_timestamp` | timestamp | UTC block timestamp for parent block |
| `ctoken` | address | Address of cToken |
| `ctoken_symbol` | string | Symbol of cToken |
| `liquidator` | address | Address that initiated the liquidation |
| `ctokens_seized` | number | cToken collateral held by the insolvent borrower that is taken by the liquidator |
| `liquidation_amount` | number | Native amount liquidated (decimal adjusted) |
| `liquidation_amount_usd` | number | The equivalent liquidated amount in USD. Note this is computed by taking the average hourly price around the time of the tx event. |
| `liquidation_contract_address` | address | Address of liquidated token |
| `liquidation_contract_symbol` | string | Symbol of liquidated token |
| `tx_id` | string | Transaction id for this liquidation |

View File

@ -0,0 +1,27 @@
# Market Stats
Market Stats exist within the `compound` schema, as `compound.market_stats`
| **Field** | **Type** | Description |
| ----------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `block_hour` | string | Market stats are aggregated by hour in UTC. `date_trunc(hour,block_timestamp)` for joins on other tables |
| `contract_name` | string | market/cToken name |
| `ctoken_address` | address | market/cToken address (i.e. cUSDC) |
| `underlying_contract` | address | Address of the underlying token the market serves (i.e. USDC) |
| `underlying_symbol` | string | Symbol of the underlying token the market serves |
| `token_price` | number | Price of the underlying token (i.e. USDC) |
| `ctoken_price` | number | Price of the cToken (i.e. cUSDC) |
| `reserves_token_amount` | number | Reserves are amounts set aside by the market that can be used/affected by governance actions through proposals voted on by COMP holders |
| `borrows_token_amount` | number | Amount borrowed from the market |
| `supply_token_amount` | number | Amount (in terms of the cToken) supplied to the market through suppliers |
| `supply_usd` | number | Supply converted to USD values as of the hour recorded |
| `reserves_usd` | number | Reserves converted to USD values as of the hour recorded |
| `borrows_usd` | number | Borrows converted to USD values as of the hour recorded |
| `comp_speed` | number | COMP is a governance token distributed equally to both suppliers and borrowers (the idea being the users of the protocol are also the ones who should be able to vote on governance actions). Comp speed controls the rate at which comp is distributed to users of the market, per block |
| `supply_apy` | number | The suppliers APY in terms of the underlying asset. It depends on the exchange rate between the cToken/underlying token (cUSDC/USDC). This is interest paid to the supplier for their stake |
| `borrow_apy` | number | The borrowers APY in terms of the underlying asset. It depends on the exchange rate between the cToken/underlying token (cUSDC/USDC). This is interest paid by the borrower on their loan |
| `comp_price` | number | The price of the COMP governance token |
| `comp_speed_usd` | number | Comp distributed to markets converted to USD |
| `comp_apy_borrow` | number | The APY one can expect based on COMP governance tokens distributed (which in turn can be staked elsewhere, or used in voting) |
| `comp_apy_supply` | number | The APY one can expect based on COMP governance tokens distributed (which in turn can be staked elsewhere, or used in voting) |

View File

@ -0,0 +1,18 @@
# Deposits
Deposits exist within the `compound` schema, as `compound.deposits`
| Field | Type | Description |
| --------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------- |
| `block_id` | number | The block height this event was recorded at |
| `block_timestamp` | timestamp | UTC block timestamp for parent block |
| `ctoken` | address | cToken address |
| `ctoken_symbol` | string | cToken symbol |
| `issued_tokens` | number | Amount of cToken issued for providing liquidity |
| `supplied_base_assets` | number | Native amount provided as liquidity (decimal adjusted) |
| `supplied_base_assets_usd` | number | The equivalent liquidity amount in USD. Note this is computed by taking the average hourly price around the time of the tx event |
| `supplied_contract_address` | address | Address of token provided liquidity for |
| `supplied_symbol` | string | Symbol of token provided liquidity for |
| `supplier` | address | Address of liquidity provider |
| `tx_id` | string | Transaction id for this mint |

View File

@ -0,0 +1,17 @@
# Redemptions
Redemptions exist within the `compound` schema, as `compound.redemptions`
| Field | Type | Description |
| --------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------- |
| `block_id` | number | The block height this event was recorded at |
| `block_timestamp` | timestamp | UTC block timestamp for parent block |
| `ctoken` | address | cToken address |
| `ctoken_symbol` | string | cToken symbol |
| `received_amount` | number | Native amount provided as liquidity (decimal adjusted) |
| `received_amount_usd` | number | The equivalent liquidity amount in USD. Note this is computed by taking the average hourly price around the time of the tx event |
| `received_contract_address` | address | Address of token refunded as part of the redemption |
| `received_contract_symbol` | string | Symbol of token refunded as part of the redemption |
| `redeemed_ctoken` | number | cToken deposited to redeem |
| `supplier` | address | Address of liquidity provider |
| `tx_id` | string | Transaction id for the redemption(s) |

View File

@ -0,0 +1,19 @@
# Repayments
Repayments exist within the `compound` schema, as `compound.repayments`
| Field | Type | Description |
| ------------------------ | --------- | ----------------------------------------------------------------------------------------------------------------------------- |
| `block_id` | number | The block height this event was recorded at |
| `block_timestamp` | timestamp | UTC block timestamp for parent block |
| `borrower` | address | Address of initial borrower |
| `ctoken` | address | cToken address |
| `ctoken_symbol` | string | cToken symbol |
| `payer` | address | Address of user that paid out the loan |
| `repay_contract_address` | address | Address of token refunded as part of the redemption |
| `repay_contract_symbol` | string | Symbol of token refunded as part of the redemption |
| `repayed_amount` | number | Native amount repaid on loan (decimal adjusted) |
| `repayed_amount_usd` | number | The equivalent repaid amount in USD. Note this is computed by taking the average hourly price around the time of the tx event |
| `tx_id` | string | Transaction id for this repayment |

View File

@ -0,0 +1,7 @@
# Crosschain Tables
These tables contain data from multiple blockchains. The following tables are available in this schema:\
\
Address Labels Table\
\
Address Tags Table&#x20;

View File

@ -0,0 +1,17 @@
# Crosschain Address Labels
### Table Schema
`crosschain.address_labels`
| Field | Type | Description |
| ------------------- | --------- | -------------------------------------------------------------------------- |
| system\_created\_at | timestamp | The time when the label was sent to the table. |
| insert\_date | timestamp | The date the label was inserted into the table. |
| blockchain | string | The name of the blockchain. |
| creator | string | The name of the creator of the label. |
| address | string | The address the label belongs to. Use this to join to other tables. |
| label\_type | string | A high-level category describing the addresses main function or ownership. |
| label\_subtype | string | A sub-category nested within label type providing further detail. |
| address\_name | string | Name of the address or the label. |
| project\_name | string | Name of the controlling entity of the address. |

Some files were not shown because too many files have changed in this diff Show More