GitBook: [#302] No subject
BIN
.gitbook/assets/Screen Shot 2019-12-02 at 5.17.10 PM.png
Normal file
|
After Width: | Height: | Size: 104 KiB |
BIN
.gitbook/assets/Screen Shot 2019-12-02 at 5.21.49 PM.png
Normal file
|
After Width: | Height: | Size: 102 KiB |
BIN
.gitbook/assets/Screen Shot 2019-12-02 at 5.22.56 PM.png
Normal file
|
After Width: | Height: | Size: 106 KiB |
BIN
.gitbook/assets/Screen Shot 2019-12-03 at 10.35.52 PM.png
Normal file
|
After Width: | Height: | Size: 39 KiB |
BIN
.gitbook/assets/Screen Shot 2020-11-01 at 10.30.54 PM.png
Normal file
|
After Width: | Height: | Size: 140 KiB |
BIN
.gitbook/assets/Screen Shot 2020-11-01 at 11.15.42 PM.png
Normal file
|
After Width: | Height: | Size: 98 KiB |
BIN
.gitbook/assets/Screen Shot 2020-11-01 at 11.32.21 PM.png
Normal file
|
After Width: | Height: | Size: 120 KiB |
BIN
.gitbook/assets/Screen Shot 2020-11-08 at 8.29.00 PM.png
Normal file
|
After Width: | Height: | Size: 106 KiB |
BIN
.gitbook/assets/Screen Shot 2020-11-08 at 8.36.02 PM.png
Normal file
|
After Width: | Height: | Size: 98 KiB |
BIN
.gitbook/assets/Screen Shot 2020-11-08 at 9.51.22 PM.png
Normal file
|
After Width: | Height: | Size: 122 KiB |
BIN
.gitbook/assets/Screen Shot 2021-04-20 at 11.44.31 AM.png
Normal file
|
After Width: | Height: | Size: 197 KiB |
BIN
.gitbook/assets/Screen Shot 2021-08-16 at 3.22.45 PM.png
Normal file
|
After Width: | Height: | Size: 25 KiB |
BIN
.gitbook/assets/Uniswap V3 - Copy of uniswapv3 silver_tables.png
Normal file
|
After Width: | Height: | Size: 126 KiB |
BIN
.gitbook/assets/Uniswap V3 - Factory.png
Normal file
|
After Width: | Height: | Size: 502 KiB |
BIN
.gitbook/assets/Uniswap V3 - NonFungiblePositionManager.png
Normal file
|
After Width: | Height: | Size: 702 KiB |
BIN
.gitbook/assets/Uniswap V3 - Pool.png
Normal file
|
After Width: | Height: | Size: 1.1 MiB |
BIN
.gitbook/assets/Untitled
Normal file
|
After Width: | Height: | Size: 100 KiB |
BIN
.gitbook/assets/Untitled 1
Normal file
|
After Width: | Height: | Size: 170 KiB |
BIN
.gitbook/assets/Untitled 2
Normal file
|
After Width: | Height: | Size: 36 KiB |
BIN
.gitbook/assets/Velocity Documentation - EventContext (1).png
Normal file
|
After Width: | Height: | Size: 14 KiB |
BIN
.gitbook/assets/Velocity Documentation - EventContext.png
Normal file
|
After Width: | Height: | Size: 13 KiB |
BIN
.gitbook/assets/Velocity Documentation - Labels.png
Normal file
|
After Width: | Height: | Size: 30 KiB |
BIN
.gitbook/assets/Velocity Documentation - Page 1.png
Normal file
|
After Width: | Height: | Size: 27 KiB |
BIN
.gitbook/assets/image (1).png
Normal file
|
After Width: | Height: | Size: 15 KiB |
BIN
.gitbook/assets/image (2).png
Normal file
|
After Width: | Height: | Size: 100 KiB |
BIN
.gitbook/assets/image (3).png
Normal file
|
After Width: | Height: | Size: 100 KiB |
BIN
.gitbook/assets/image (4).png
Normal file
|
After Width: | Height: | Size: 170 KiB |
BIN
.gitbook/assets/image (5).png
Normal file
|
After Width: | Height: | Size: 107 KiB |
BIN
.gitbook/assets/image.png
Normal file
|
After Width: | Height: | Size: 15 KiB |
BIN
.gitbook/assets/params.png
Normal file
|
After Width: | Height: | Size: 14 KiB |
BIN
.gitbook/assets/pass.png
Normal file
|
After Width: | Height: | Size: 456 KiB |
184
.gitbook/assets/rest_api.yml
Normal 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/
|
||||
188
.gitbook/assets/restapi_docs.yml
Normal 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/
|
||||
23
README.md
@ -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
@ -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)
|
||||
90
our-data/contribute-to-flipside-data.md
Normal 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 , I’m interested in doing data curation for Flipside, could you give me snowflake access please? I’d 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 don’t 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! You’ve successfully contributed a data model!**
|
||||
23
our-data/data-models/README.md
Normal 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. 
|
||||
|
||||
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/). 
|
||||
|
||||
Let's start by exploring Flipside's [event model](events-data-model.md). 
|
||||
|
||||
{% content-ref url="events-data-model.md" %}
|
||||
[events-data-model.md](events-data-model.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
24
our-data/data-models/balances.md
Normal 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. 
|
||||
|
||||
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. 
|
||||
* 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. 
|
||||
* Label fields are left blank (NULL) if the address is unlabeled.
|
||||
60
our-data/data-models/events-data-model.md
Normal 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.
|
||||
|
||||
.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.
|
||||
|
||||

|
||||
|
||||
### 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. 
|
||||
{% 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).
|
||||
23
our-data/data-models/facts-and-dimensions.md
Normal 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.
|
||||
49
our-data/data-models/labels/README.md
Normal 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. 
|
||||
|
||||
See [the Crosschain schema](../../tables/crosschain-tables-1/crosschain-address-labels.md) for a table containing all labeled addresses. 
|
||||
|
||||
Flipside applies a 2-level hierarchy to all labeled addresses using 4 field attributes. 
|
||||
|
||||
|
||||
|
||||

|
||||
|
||||
| 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)
|
||||
|
||||
19
our-data/data-models/labels/cex-label-type.md
Normal file
@ -0,0 +1,19 @@
|
||||
# Centralized Exchange Label Type
|
||||
|
||||
Centralized Exchanges are referred to as `cex` in the Flipside label system. 
|
||||
|
||||
`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 exchange’s 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 |
|
||||
|
||||
15
our-data/data-models/labels/chadmin-label-type.md
Normal 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 |
|
||||
|
||||
|
||||
27
our-data/data-models/labels/defi-label-type.md
Normal 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 |
|
||||
26
our-data/data-models/labels/dex-label-type.md
Normal 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 |
|
||||
15
our-data/data-models/labels/flotsam-label-type.md
Normal 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 |
|
||||
12
our-data/data-models/labels/layer2-label-type.md
Normal 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 |
|
||||
17
our-data/data-models/labels/nft-label-type.md
Normal 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 |
|
||||
|
||||
14
our-data/data-models/labels/operator-label-type.md
Normal 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 |
|
||||
|
||||
18
our-data/data-models/labels/other-label-type.md
Normal 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 |
|
||||
11
our-data/data-models/labels/token-label-type.md
Normal 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. 
|
||||
|
||||
|
||||
|
||||
### Label Subtypes
|
||||
|
||||
| Subtype | Description |
|
||||
| ---------------- | --------------------------------------- |
|
||||
| `token_contract` | ERC-20 token (fungible token) contract |
|
||||
149
our-data/data-models/tags.md
Normal file
@ -0,0 +1,149 @@
|
||||
# Tags
|
||||
|
||||
Tags identify traits or behaviors that belong to an address. 
|
||||
|
||||
For a table of all tagged addresses see [the Crosschain schema](../tables/crosschain-tables-1/crosschain-address-tags.md). 
|
||||
|
||||
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. 
|
||||
|
||||
Your tags. Your rules. 
|
||||
|
||||
## How are tags different than labels? 
|
||||
|
||||
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. 
|
||||
|
||||
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. 
|
||||
|
||||
|
||||
|
||||
## 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. 
|
||||
|
||||
|
||||
|
||||
## How to query tags
|
||||
|
||||
It's important to remember that a particular address can (and should) have multiple tags. 
|
||||
|
||||
**BE CAREFUL WHEN JOINING TO THE TAGS TABLE, SO YOU DON'T DUPLICATE ROWS.** 
|
||||
|
||||
|
||||
|
||||
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. 
|
||||
|
||||
|
||||
|
||||
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
@ -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. 
|
||||
|
||||
****
|
||||
|
||||
**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.** 
|
||||
|
||||
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. 
|
||||
|
||||
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
@ -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. 
|
||||
|
||||
### 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 %}
|
||||
|
||||
77
our-data/tables/aave-tables/README.md
Normal 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)?
|
||||
|
||||

|
||||
|
||||
Aave a few different subsets of markets, shown above. 
|
||||
|
||||
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 %}
|
||||
|
||||
26
our-data/tables/aave-tables/borrows.md
Normal 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) |
|
||||
|
||||
|
||||
|
||||
22
our-data/tables/aave-tables/deposits.md
Normal 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) |
|
||||
|
||||
28
our-data/tables/aave-tables/flashloans.md
Normal 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) |
|
||||
|
||||
|
||||
|
||||
29
our-data/tables/aave-tables/liquidations.md
Normal 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) |
|
||||
|
||||
36
our-data/tables/aave-tables/market-stats.md
Normal 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 reserve’s 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.
|
||||
|
||||
19
our-data/tables/aave-tables/proposals.md
Normal 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) |
|
||||
26
our-data/tables/aave-tables/repayments.md
Normal 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) |
|
||||
|
||||
|
||||
|
||||
16
our-data/tables/aave-tables/votes.md
Normal 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) |
|
||||
24
our-data/tables/aave-tables/withdraws.md
Normal 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) |
|
||||
|
||||
|
||||
|
||||
12
our-data/tables/algorand-tables/README.md
Normal 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" %}
|
||||
|
||||
|
||||
|
||||
@ -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.
|
||||
@ -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 |
|
||||
@ -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. |
|
||||
@ -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 |
|
||||
15
our-data/tables/algorand-tables/algorand-base-tables/app.md
Normal 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 | |
|
||||
|
||||
@ -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) 
|
||||
|
||||
## 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. 
|
||||
|
||||
| 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 |
|
||||
|
||||
@ -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. 
|
||||
|
||||
| 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 |
|
||||
@ -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. 
|
||||
|
||||
| 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 |
|
||||
@ -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. 
|
||||
|
||||
| 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 |
|
||||
@ -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 |
|
||||
@ -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 |
|
||||
@ -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 |
|
||||
@ -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. 
|
||||
|
||||
| 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 |
|
||||
@ -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. 
|
||||
|
||||
| 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 |
|
||||
@ -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 |
|
||||
@ -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 |
|
||||
@ -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 |
|
||||
@ -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 |
|
||||
|
||||
@ -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) . 
|
||||
|
||||
## 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. 
|
||||
|
||||
| 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 |
|
||||
@ -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. 
|
||||
|
||||
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. 
|
||||
|
||||
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 |
|
||||
25
our-data/tables/arbitrum-tables.md
Normal 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)`. 
|
||||
|
||||
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)__
|
||||
6
our-data/tables/astroport-tables/README.md
Normal file
@ -0,0 +1,6 @@
|
||||
# Astroport Tables
|
||||
|
||||
Astroport is an automated market-maker (AMM) protocol on the Terra blockchain. 
|
||||
|
||||
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."
|
||||
|
||||
20
our-data/tables/astroport-tables/lp-actions.md
Normal 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. 
|
||||
|
||||
| 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 |
|
||||
32
our-data/tables/astroport-tables/swap.md
Normal 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. 
|
||||
|
||||
|
||||
|
||||
## 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 |
|
||||
25
our-data/tables/avalanche-tables.md
Normal 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)`. 
|
||||
|
||||
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)``
|
||||
*  [`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)__
|
||||
23
our-data/tables/bsc-tables.md
Normal 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)`. 
|
||||
|
||||
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)``
|
||||
58
our-data/tables/compound-tables/README.md
Normal 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. 
|
||||
|
||||

|
||||
|
||||
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:** 
|
||||
|
||||
* 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**:
|
||||
|
||||
*  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! 
|
||||
* 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)! 
|
||||
|
||||
  [https://compound.finance/docs/ctokens#key-events](https://compound.finance/docs/ctokens#key-events)
|
||||
17
our-data/tables/compound-tables/borrows.md
Normal 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 |
|
||||
|
||||
17
our-data/tables/compound-tables/liquidations.md
Normal 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 |
|
||||
27
our-data/tables/compound-tables/market-stats.md
Normal 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 supplier’s 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 borrower’s 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) |
|
||||
|
||||
18
our-data/tables/compound-tables/mints.md
Normal 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 |
|
||||
|
||||
17
our-data/tables/compound-tables/redemptions.md
Normal 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) |
|
||||
19
our-data/tables/compound-tables/repayments.md
Normal 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 |
|
||||
7
our-data/tables/crosschain-tables-1/README.md
Normal 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 
|
||||
@ -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. |
|
||||