On-chain data is very powerful. It contains the truth about everything that has ever been immutably written in digital stone. But it is a lot of data. Our Credmark ETL has thus far recorded 16 GB of data

So if you are looking to understand this massive amount of data, you need to use tools. And one of the most efficient tools to understand whopping amounts of data is to visualize it and look for patterns.

At Credmark we organize and produce data, but we don’t build visualization tools. Nonetheless, we wanted to see it ourselves, and we wanted to show others an example of the data we produce. We wanted to connect all the dots to show what we have to offer. Ideally, we wanted to inspire people to think even further about the possibilities that lay beyond the raw data.

For us, it was important to demonstrate the blend between on-chain data and useful risk analysis for DeFi. So we built a showcase, the 

Sure, there are dashboards out there….there are thousands of them. So why release yet another one?

Well, simple. Ours is different. And we don’t only mean the nice design and the interactivity. Most importantly, the data that drives this dashboard is different. This data that has not been seen in any other dashboard. This data is the product of financial risk analysis models that use on-chain data as their source. These models were built and deployed on the Credmark Platform.

As we are very proud of what is possible with the Terminal, we want to get a step further and dive into some “real world” examples, to show how you can visualize our data from the Terminal to gain insights into what is going on in the markets. This data, of course, is also directly available on our platform or through one of our APIs.

We will now highlight some of the metrics we have in the Terminal. The first one will be the 

2022 is a weird time to be in Crypto. Some heavy macro events pulled us down. We had the Terra / Luna debacle as well as the fallout of 3AC, BlockFi, Voyager, Celsius….but the biggest 💩 of all was set to come in the form of SBF and his Alameda / FTX empire.

While FTX was a centralized exchange (CEX), they (and Alameda even more) had their claws in DeFi as well. And as soon as they leave their centralized orderbooks and OTC trading desks, and enter the main stage on the blockchain, they leave traces. And we are able to pick them up.

Liquidity is king... but for which tokens?

So with every crisis there comes the liquidity crunch. Degens flew out from risky assets into some safe havens like USDC or DAI. But what about other so-called stablecoins? Remember that Alameda was a major user of Abracadabra, and they used FTT (FTX´s own utility token) to mint Magic Internet Money (MIM). And they minted A LOT. As on November 3rd, more than 35% of the outstanding MIM supply was backed by FTT¹.

As the rumors about Alameda surfaced and CZ officially announced his selloff plan for FTT, users flew from MIM. And you could follow it live on the biggest decentralized stablecoin exchange of all….Curve.

Here we see some direct insights that the Terminal offers us. We see the trading volume and total value locked (TVL) in the 3Crv/MIM pool but, most importantly, we see the Balance Ratio on the top left.

In short, the Balance Ratio shows how unbalanced the pool is. A number close to 1 means perfectly balanced, so if there are two assets in the pool, each one makes up roughly 50%. When there are 3 assets in the pool and each individual one is about 33%, you would consider this pool also perfectly balanced and the Balance Ratio would show a number close to 1.

The Balance Ratio of the 3Crv/MIM pool reached a low of 0.3535 on Nov 8. The Balance Ratio recovered recently, but the Curve pool is still very unbalanced towards MIM with over 86%.

People were selling MIM against the other stablecoins of the pool, thus causing sell-pressure against the peg of MIM. This finally caused MIM to depeg to $0.95 on Nov 8th but soon restored the peg again.

But not only was MIM under pressure, so was USDT, which raised concerns worth looking at. The 3Pool on Curve (DAI/USDC/USDT) shows some significant imbalance as well, with a share of 13.9% DAI, 12.5% USDC, and 73.5% USDT, instead of the ideal 33% split.

You will see the change in the Balance Ratio chart for the 3pool in the Terminal as well as rise in the trading volume. The Balance Ratio tanked from nearly 1 to 0.3634 while the Trading Volume spiked from below $100m daily volume to over $2b.

You can draw your own conclusions from these charts, but in general, investors seemed to limit their exposure to USDT and once again favor USDC and DAI instead.


Imbalances in Curve pools should always be watched closely as they are indicators that something is going on in the markets. So every savvy investor should pay attention to this very important metric and Credmark´s data, available via our APsI or the Terminal, should be your go-to source.

Insights from the FTX implosion (Bankless Substack)

Data retrieved from Curve.fi/#/ethereum/pools/mim/deposit

https://curve.fi/#/ethereum/pools/3pool/deposit

 runs a financial modeling platform powered by reliable 

 of quants, developers, and modelers actively build models for the DeFi community by leveraging our data API and tools. Join the growing community and together we will advance the next-generation financial system.

The Credmark Terminal and FTX

Visualizing On-Chain Data (Part 1)

Special thanks to Paul Murphy from Credmark for feedback, Vineet and Kunlun for help getting onboarded to the CMF.

Many Web3 data analysts are familiar with the SQL-based platforms for accessing on-chain data. Popular providers like Dune Analytics and FlipSideCrypto, among others, come to mind. There are situations where alternative data sources are desirable.

You may need to stream data to power your startup’s application.

You may need to create predictive models, run portfolio risk simulations, or dig into a DeFi protocol’s equations - many of which may better be accomplished in a Python environment.

You may want to cross-reference various data sources to ensure you’re getting accurate price data (

: Credmark uses a novel approach to solving the problem of getting reliable prices off DEXs. See their 

For these situations and more, Credmark is a fantastic option that all data teams should consider for their stack.

Credmark is a blockchain data curator made by developers, for developers. Their target audience has historically been developers and quants. For those coming from ready-to-query SQL-based platforms, there is a bit of a learning curve.

Beyond simply providing API endpoints, Credmark has created a platform, “The Credmark Model Framework”, that allows both consumers of data (i.e., data analysts) and creators of data models to create composable data models, publish them and collect rewards for their work. This is analogous to subgraph developers publishing subgraphs to The Graph’s platform.

In this article, I’ll walk through a setup of the Credmark Model Framework from the perspective of a Data Analyst who is primarily interested in querying data. The goal is to lower the learning curve allowing more analysts to use this platform.

These steps can be worked through on this 

, you’ll want to have this page opened in another window. I’ll go over the steps again here in this post, with additional commentary for analysts who may not be familiar with Python. There are some prerequisites needed to prepare your local environment for interacting with the Credmark Model Framework. You’ll want to secure the following:

Install Python version 3.9+ or Miniconda 4.10+

A personal web3 provider URL blockchain node (e.g., an Alchemy HTTPS, under API Key) to run the model

VSCode (or a preferred Integrated Development Environment)

(The assumption is that you’re on a macOS)

Credmark’s Models are stored on a Github repository that you’ll need to Fork, then Clone on your local computer. Then you’ll set up a virtual environment.

For those unfamiliar with Python, googling “python virtual environment” will yield an endless stream of resources. The tl;dr of all this is Credmark’s Model Framework is written in Python, which among other things, allows for model composability - an advanced feature that may not be of immediate concern for the data analyst. However, consequently, analysts who are more interested in querying data have to get comfortable with Python.

But what about ‘virtual environments’?

The Credmark Model Framework comprises Python classes and modules. Users of the framework have to download several popular external data libraries like pandas, numpy, matplotlib among others. To ensure that these libraries (dependencies) don’t get entangled with other projects you may be working on, a virtual environment allows you to create a self-contained environment for when you need to interface with the Credmark Model Framework.

 that the most hassle free way to set up a virtual environment is to use the Anaconda Distribution (but some people may prefer Python venv).

It is important to create and activate your Python virtual environment before you proceed with installing dependencies. You’ll run the next couple commands in your terminal (shell) to list out environments, create one, then make sure you are in that environment.

Note: After you finish working, you can deactivate your virtual environment:

) and configure your environment which involves 

 a Credmark API Key and an Alchemy (or Infura) URL blockchain node.

Next you’ll set up a configuration file at the root of the 

 directory (that you forked and cloned locally, see above), specifically called an “.env” (dot env) file to contain:

Storing your API keys in this ‘.env’ file helps prevent it from being uploaded to a public github repository. To double check, you’ll also want to make sure that the ‘.gitignore’ file (also at the root directory) contains ‘.env’ (under the #Environments section). This prevents you from pushing sensitive information to Github, if and when you decide to commit to your own github repository.

Moreover, sensitive information like API Keys and Alchemy HTTPS url endpoints are in a 

 from your Python script that you’ll use to query data.

If you’re following along the CMF Model Guide documentation, at this point, you’ve completed 

. The rest of the documentation will be of interest if you intend to 

 models, but the assumption for the rest of this post is that as a data analyst, your first task is to query 

First you’ll try out a sample query in your terminal, but in order for it to work, you have to be in the “

” directory. Starting at the root directory the path is /credmark-models-py/models. This won’t work unless you’re in the 

Once you’ve changed directory into the 

 directory, then you can run a sample query in the terminal:

This should yield the current price of WBTC (you can also substitute it for WETH or ETH or a number of other popular ERC20 tokens). It’s worth noting that symbols are used here for convenience and Credmark maintains a list of verified symbols, however, using the full hexadecimal address will minimize errors.

To anticipate a possible error message, you may run into the following:

This means you need to enter another command to set the $PATH to where the command ‘credmark-dev’ is stored by entering the following (note: you may need to customize the following to your version of Python).

If this doesn’t work for you, you may have to Google: “zsh: command not found:” and apply recommendations to your local machine context (i.e., which directory Python is stored on your machine etc).

Once you get results in the terminal, you can create a Python script to handle both data ingestion and some light transformation.

For this example, we’ll query historical prices. While you can also run this command in the terminal, historical data output can be quite long so handling data and doing light transformations in a python script is more suitable.

Here are the modules we’ll use to run the next few operations.

First, create and save a file. I’ll name mine stableprice.py, but you can name it anything that makes sense to you.

 module allows us to run terminal/shell commands 

 allows us to transform our data; you may want to transform it to dataframe as tabular data is easier to manipulate; 

 allows us to print nested dictionaries in a cleaner way and finally, the 

 module allows us to convert string data types to dictionaries.

, i’ll be querying USDC prices for the past 30-days. Below I'm taking a command that could be run in the terminal and breaking it up as a 

We are taking a command that would be one line in terminal:

And breaking it up into segments as a python subprocess:

We’ve pointed the data at a variable ‘usdc’, which we can further handle. The data that is returned from the Credmark Model Framework are in the 

Once in dictionary form, we can better decide which 

 pair to move forward with. At this point, the data can be transformed to a 

In a future post, we’ll explore other Credmark Models as well as build an intuition for looking up the 

 is a decentralized Capital-as-a-Service (CaaS) protocol enabling Web3 organizations to grow, monitor, and manage the risks of their idle crypto capital.

Guest Post

Onboarding to the Credmark Model Framework for Data Analysts

Decentralizing Crypto Prices is necessary to advance web3

Read more about Credmark's solution for deriving prices off of DEXes

Here's how CeFi manipulate crypto prices and why DeFi prices are better

How often have you used a data API that gave you everything you needed? My answer to that question is NEVER.

You are happily using “The Official Star Wars API” to retrieve the names and images of the actors who played Star Wars characters. You display them like trading cards in a sexy website using your favorite framework. You even make them searchable. Everyone loves it.

But one day your boss walks in and asks you to add the actors’ birth dates to their cards. “No problem,” you tell her, figuring there must be an endpoint for retrieving such basic information. Unfortunately, there isn’t. You contact Disney’s support team and you’re told: “It’s on our roadmap.”

Now you have to find another API or, worse, gather the data manually. You’re unhappy with both options.

Like the Star Wars series, the above example is pure fiction. Unfortunately, hitting the API brick wall isn’t. It happens all the time.


 to retrieve current and historical token prices.

This is how you retrieve the latest price for the Aave token using the Token API, for example:

Picante recently came to us and asked if we could price DEX LP tokens. Specifically they asked for Uniswap v2, Uniswap v3, and SushiSwap tokens. We solved their problem in a few hours.

So now, Picante users who provide liquidity to DEXes can see both their liquidity and the fees they’ve earned, right in their Picante dashboard.

Are we magicians? I’m afraid not. In a few hours we couldn’t possibly

implement a new endpoint in our Token API,

That would be impossible. It also wouldn’t make much sense. We can’t keep adding endpoints to an otherwise generic API. 99% of our customers could care less about LP tokens!

Here’s something most people don’t know:

Under the hood of all our APIs (Token, Portfolio, and Protocol) sits the Credmark Platform. This platform allows developers to easily build and deploy financial models leveraging our base layer of crypto data. Every API endpoint calls a model deployed on the Credmark Platform.

But not every model has a corresponding API endpoint. Most are too esoteric. For every API endpoint we publish, approximately ten related models are deployed on the platform.

Any of those models can be called directly using our special API that we call the 

, which has exactly one endpoint. That endpoint is the ultimate escape hatch.

This is how you retrieve the price of a Uniswap v3 token using the DeFi API for example:

No matter how strange or unique your request might be, we can (almost) always address it by building and deploying a custom model. Or you can build and deploy it using the open source 

Technically-speaking our Token API isn’t extensible, but practically-speaking, it is. In fact, all our APIs are both constrained and extensible. They are constrained by design and don’t try to accommodate every possible case. They address the most common ones, as simply as possible. This is how we think APIs should be designed.

Constraints are great, until they aren’t.

At some point everyone needs an escape hatch. At Credmark we’re proud to have designed one into the very core of our product suite.

Limitless Possibilities

Credmark’s Token API is Extensible 🤯

A few weeks ago I wrote a post titled “

”. I pointed out the absurdity of the current situation:

 – i.e., prices provided by centralized exchanges – are opaque and unreliable. 

 – i.e., prices derived from on-chain data – are transparent and verifiable.

Several readers asked me to explain why lack of transparency is a problem. Here goes.


Before going any further I’m going to quickly review how centralized and decentralized exchanges work. This is going to be very high-level since I’m essentially condensing a book into a few paragraphs. There are lots of variations on these themes, but those don’t matter in this context.

Centralized exchanges (CEXes) are based on order books. For every trading pair the exchange keeps track of what traders are willing to pay for a certain amount of another asset (bid) and what other traders are willing to accept (ask). When bids and asks match, a trade is made. Although exchange personnel have a big incentive to behave ethically (jail), they are human, and market makers’ incentives don’t always align with traders’.

Decentralized exchanges (DEXes) are based on automated market makers. These are smart contracts that perform two functions:

Liquidity can be provided by anyone and is usually provided as a pair, i.e., some of each asset in the trading pool.

When a user wants to swap asset A for asset B, A is added to the pool and B is extracted. The ratio of A to B determines the price. When the ratio changes, the price changes as well.

Most exchange manipulation has one goal: provide misleading information to the market. This information can be price, volume (a proxy for interest), or even volatility. Knowing that everyone believes something that isn’t true, or vice-versa, is an easy way to make money!

In a CEX environment bots can be used for all sorts of nefarious purposes, i.e., generating

In DeFi, bots are primarily used for arbitrage, which is a net positive. These bots guarantee that prices between liquidity pools remain constant. Of course bots running against DEXes have been used to achieve the same ends as CEX bots, but it’s far more difficult due to the transparent nature of DeFi. After all, everything is recorded on a public blockchain.

Wash trading is buying an asset from one counterparty and then immediately selling it to another. This generates fake volume. It’s illegal, but it happens all the time on centralized exchanges.

On DEXes it would be a waste of time since both transactions would be visible to the world.

Fake volumes, prices, and momentum are easy to exploit if you know they’re fake. As mentioned earlier, this misleading data could be intentionally created using bots, or even live traders. Sometimes the source could be harder to track down: unusual trading activity, rumors, or incorrect reporting can all lead traders to make the wrong assumptions.

Trading on DEXes doesn’t of course protect a trader from all of these, but, in general, transparency makes them less likely to succeed.

Sometimes unknown actors within exchanges can force the reporting of incorrect prices. We saw this clearly during UST’s collapse. While UST’s price fell steadily on DEXes, Binance artificially reported it at c. $0.70. 

The chart below shows prices reported by Binance vs. prices Credmark derived from DEX data. It clearly shows the trading floor set by Binance while the token price was collapsing. Interestingly, the floor seems to have had its intended effect as the price rose after a few minutes on the Binance exchange while continuing to collapse on DEXes.

The artificial intervention to “instill confidence” ultimately failed. No matter the intention, the fake price was damaging to holders of UST who might have sold sooner had they realized that market confidence in the asset had evaporated.

DeFi doesn’t rely on a single exchange feed like Binance, it relies on oracles which derive their prices from a large number of feeds, most of which are centralized.

 after the LUNA collapse, oracles can also be misconfigured and, as a result, report incorrect prices. As the LUNA price was collapsing, Chainlink (a centralized organization managing decentralized data sources from mostly centralized exchanges 🤷🏻‍♂️) paused the LUNA price feed when it was reporting a price of $0.107. Unfortunately, traders continued to act on this price as the real price fell below $0.01.

Anyone relying on Chainlink prices was in the dark. Clever traders exploited this “mistake” and made millions of dollars. Naturally, other people lost millions of dollars.

It’s very clear that prices derived from public DEX data are more fair than prices reported by CEXes. 

The shenanigans and mistakes that can affect prices on centralized exchanges are endless. I’ve only mentioned a few. In traditional finance, an entire regulatory infrastructure exists to discover price manipulation and punish the people engaging in them.

Ultimately, both accurate and inaccurate prices are published and become part of history.

We argued last week that prices derived from DEX data were both more transparent and more democratic. Transparency makes manipulation more difficult, a huge benefit. Democratic data is available to everyone, so anyone can act on it without fear that of being exploited by someone who knows more than they do.

DeFi > CeFi

Decentralized Prices are Better than Centralized Prices

How to install and run the Model Framework

Token prices are the base layer of just about every economic activity in the crypto universe. How much are your tokens worth? How well has your portfolio performed? Is this a good trade? Does staking this token make sense?

Without prices, we can’t answer those questions. Without accurate prices, we might not make the right decisions.

Prices matter, a lot. And since they matter so much, we should ask ourselves a few questions.

Token prices almost always come from centralized exchanges (CEXes). Sometimes synthetic prices are created by blending prices from multiple exchanges.

For traders using those exchanges, these price sources make sense. Those are, after all, the prices they have or could have gotten.

DeFi smart contracts get their prices from an oracle. And where do oracles get their prices? Mostly from CEXes, which is odd since decentralized exchanges (DEXes) are a fundamental part of DeFi.

When a developer uses CoinGecko’s API to retrieve prices, can they know the sources of those prices? No. According to their documentation the data comes from 

 that the prices their API returns are from CoinGecko and “enhanced” with DeFi derived prices. And one of DeFi’s cornerstones, Dune Analytics, gets their prices from Coinpaprika, who derive their prices from their partners’, Crypto Runner and Binance.

There’s nothing wrong with synthetic prices. In traditional finance many firms exist for the sole purpose of creating synthetic prices from exchange feeds. Most publish how they produce those prices. If they didn’t, people wouldn’t buy them.

In crypto we haven’t gotten that far. Synthetic prices come out of black boxes. I’ve read documentation that claims they’re “volume weighted” or “liquidity weighted”, without any indication of how or where they acquired the volume or liquidity data.

And are any of the algorithms that produce these prices made public? Unfortunately not.

When it comes to crypto price production, we are in the dark. We don’t know the inputs and we don’t know what the black box does.

All of this makes no sense from a Web3 perspective. In fact it’s anti-Web3.

Web3 is about decentralization and transparency.

CEXes are centralized by definition, and they aren’t transparent. DEXes, in large part because they are completely transparent, are less prone to manipulation than centralized exchanges.

Over time, liquidity has been moving from CEXes to DEXes. Some tokens, e.g., stETH, can’t even be traded on centralized exchanges.

Given all this, why should DeFi depend on CEX-derived prices? It shouldn’t.

Until recently there were no good sources of DeFi-derived prices. At Credmark we thought this would be an easy thing to fix. We were wrong. It was hard. It took us six months to:

develop the algorithms that produce these prices,

modify our infrastructure to compute and store historical prices, and finally

spin up enough hardware to produce prices for the top 150 tokens for every block.

DeFi prices should be derived from DeFi data, the only transparent source of crypto data. It’s on-chain and verifiable.

Unfortunately, a developer can’t make a Web3 call to retrieve a price, because prices themselves aren’t stored on-chain. Luckily, all of the data necessary to derive accurate prices 

Credmark uses this data to produce historical and current token prices that are DeFi-native. We use liquidity and swap data from three of the largest DEXes (Uniswap v2, Uniswap v3, and SushiSwap). This data is verifiable. 

³ we use to derive these prices is published on our platform as a model. Anyone can download the source code.

The output of this pricing model is available directly from our platform using a command line utility, calling the model directly 

These prices are completely transparent, just like the DEXes that produce the raw data we use to compute them.

These prices are also democratic. By that I mean that they are prices at which any DeFi user can trade.

Centralized exchange order books are opaque and the data is often questionable. Price manipulation can happen using fake trades, for example. The lack of transparency is problematic. Decentralized exchanges are much more difficult to manipulate. The liquidity in a pool determines price, nothing else.

It’s ironic that the best DeFi prices are not available to smart contracts. It would be too expensive for them to produce prices from scratch, so they have to rely on oracles that get most of their data from centralized sources.

We look forward to seeing the emergence of other DeFi-native price providers so that we can collectively publish transparent, DEX-derived prices.

We also look forward to adding more DEXes to our raw data sources.

DEXes are growing faster than CEXes. In the future, decentralized exchanges will process more trading volume than centralized exchanges. This is inevitable.

CEX-derived price feeds will continue to matter to traders who use those exchanges. It’s time for DeFi to move on. It’s time for developers to start giving their users more reliable, transparent prices.

https://twitter.com/defillama/status/1571215888933699584?s=12

https://credmark.com/blog/credmarks-dex-pricing-model

https://gateway.credmark.com/api/#/DeFi%20API/ModelRunnerController_runModel

https://gateway.credmark.com/api/#/Token%20API/TokenApiController_getPrice

Credmark’s prices do just that

It’s Time to Decentralize Crypto Prices

¹, we changed how we compute prices based on AMM DEX data. Here’s how and why.

In traditional finance, the business of a centralized exchange (CEX) is to (1) execute trades and (2) provide price and order data. This data is used for settlement, news reporting, and analysis. In decentralized finance (DeFi), decentralized exchanges (DEXes), especially automated market maker (AMM) based DEXes, end the monopoly that centralized exchanges (CEXes) once enjoyed over trade execution and the production of price and order data.

For AMM DEXes, liquidity providers (LPs) deposit the tokens into the pool, and liquidity demanders (traders) swap in / out depending on the market price. The majority of pools include either a stablecoin or the chain’s native token. As we know, stablecoins are tokens that attempt to maintain parity with a fiat currency. Because DEX protocols record all liquidity and trade information on-chain², we can derive prices from AMM pool data. Although the price data is the relative ratio between on-chain tokens, obtaining an approximate USD³-based price is not difficult.

Derive the price ratio between the token(s) in a pool.

Route³ the relative price ratios through different pools until we reach a pool that includes a proxy for USD, i.e., a USD stablecoin.

If the original pool includes a stablecoin, step 2 is unnecessary.

This is how pricing models that rely solely on DEX data work. There are, however, four potential problems with this approach:

Stablecoins use various mechanisms to maintain their peg with the fiat currency they represent. Asset-backed stablecoins can depeg due to poor liquidity or regulatory action. Algorithmic stablecoins can also be subject to attacks that weren’t anticipated by the algorithm’s designer.

We should note that stablecoin values relative to their fiat twin are almost never 1:1. To the chagrin of bookkeepers throughout the crypto industry, it is quite normal for them to trade for a fraction of a penny below or above the peg. For large transactions, this fluctuation can be material.

In the recent past, we’ve seen several examples of permanent or temporary loss of stablecoins’ peg.

In May 2022 UST lost its peg and never recovered. Today, 1 UST is worth a fraction of a penny.

 as a result of the depeg suffered by UST and its audit issues. Unlike UST, USDT fully recovered its peg by July 2022.

On August 9th, 2022 USDC fluctuated more than it usually does as a result of the 

US Treasury’s sanctions against Tornado Cash⁵.

It is incorrect to assume that, at every point in time, a stablecoin is worth one of its fiat twins. Unless we can determine the true value of a basket of stablecoins, the derived fiat price of another token cannot be determined. We will discuss our solution in a later section.

Two Liquidity Problems: Measurement and Market Depth

Liquidity is a market feature whereby a token can be sold or bought quickly without causing a significant price change because of the execution. Quantitatively, liquidity can be calculated for two kinds of scenarios: “the quantity to be traded with minimal price impact”, and “the maximum price slippage for a specific trade size and direction”. From these scenarios, we define the two liquidity problems as below

Credmark Blog

For the latest technical analysis, partnerships, and community updates