Credmark’s DEX Pricing Model | The DEX Pricing Problem

” we referred to tokens in Ring 1 and Ring 2 of the pricing strategy. This post describes how we selected the tokens to be included in these baskets.

To recap the core ideas from the previous post:

Our prices are derived entirely from DEX activity; no price data from off-chain sources is used.

Derived data is weighted by DEX pool liquidity.

Our model builds up prices using three conceptual rings:

Stablecoins form Ring 1. We acknowledge the peg to the USD but don’t assume it will always hold.

Ring 2 is the native token (ETH in the case of Ethereum), priced against Ring 1.

Ring 3 consists of all other tokens, priced against both Ring 2 and Ring 1.

The composition of rings 1-3 tokens are illustrated in the figure below. In this blog, we will discuss how we selected the tokens for Ring 1 and Ring 2.

Figure 1: Ring 1, 2, and 3 tokens in Credmark’s pricing model

Ring 1 is made up of only stablecoins that’s linked to the fiat dollar value.

Ring 1 stablecoins are selected using the following criteria:

Over-collateralized or fully-fiat-backed.

Sufficiently large liquidity between them to offset the depegging of the minority of the stablecoins in the pool.

Among the rest of tokens, we choose those tokens with the largest connections to the other tokens to be in Ring 2. Ring 2 tokens are selected using the following criteria:

They are used as a liquidity source for other tokens.

In previous blog post, we had the liquidity-weighted pricing formula as following

If we only have two stablecoins in Ring 1, we can only determine the relative value between the two. For example::

For two stablecoins Ta and Tb, there is a pool with 1000 Ta and 1 Tb.

Apply (1), Price of Ta = 0.001 * 1000 = 1, Price of Tb = 1000 * 1 = 1000. However, it could also be the case that Ta = 0.001 and Tb = 1.

In Ring 1 we need at least three stablecoins and they must meet the following criteria:

The majority of the stablecoins in the pool are pegged to their fiat twin. Slight deviation from the 1:1 ratio is permissible.

All stablecoins have sufficiently large liquidity to offset any depegged stablecoins in the pool.

Let’s consider the case when Token 0 is depegged and we need to price token n. 

The numerator in (1) can be split for the term for Token 0

In order for Token 0 to have no material impact, the term for Token 0

needs to be insignificant relative to the term for other tokens

Let’s try some real numbers. The table below shows three pools for three tokens, Ta, Tb, and Tc, with Tc depegged.

To calculate the price of Tb, we take the input of ratio and liquidity from pool no. 1 and 2.

The price of Tb = (1*1000+1000*0.01)/(1000+0.01) = 1.009989. Tb is overpriced by 1%.

When the liquidity for Tb in pool no.2 further decrease to 0.001, the price of Tb = (1*1000+1000*0.001)/(1000+0.001) = 1.000998999. Tb is overpriced by 0.1%.

In reality, traders will continue swapping Tc for Tb until the liquidity of Tb is close to zero, so the input from pool no. 2 becomes insignificant to the price of Tb. The price of Tb = (1*1000+1000*0)/(1000+0) = 1.0.

Note that if the majority depeg, our pricing algorithm will fail. When depegged event happens to the stablecoins in Ring 1, we will remove the depegged to keep the assumptions valid.

To keep our selection of the Ring 1 stablecoins stable, as we have learnt many lessons from the market (e.g. Luna/UST), we only chose those over-collateralized or fully-fiat-backed stablecoins.

For Ethereum mainnet, DAI/USDC/USDT are selected.

In the figure below, we plotted the 1-tick liquidity (available amount to move price 0.01%) for DAI/USDC/USDT in Uniswap V2/V3 and Sushiswap pools.

USDC and DAI have the larger liquidity, much more than USDT. The 1-tick liquidity has grown to 250-300 million USD for USDC and DAI. This vast amount of liquidity is the bedrock for our price equation to work.

When the USDC (orange) has higher liquidity than DAI (blue), the liquidity of USDT (green) increases. This means that USDC forms liquid pools with both DAI and USDT while DAI’s liquidity is mostly with USDC. There is not much liquidity between USDT and DAI.

We have included USDT in Ring 1 tokens for two reasons:

USDT has closely pegged to USD despite FUD surrounding Tether, USDT’s issuer. Since Q3 2022, 

How Liquidity changes for Depegged Stablecoins

The collapse of TerraClassicUSD (UST) in May 2022 was a monumental event for algorithmic stablecoins. Thanks to this event we can validate our equations.

At block 15314735 (2022-08-10), we found two pools with UST-WETH as shown in table 2 below. The liquidity of WETH is tiny in both pools. The liquidity of UST in 0x9a0c… is larger but its price is lower than that other pool. It could be in the aftermath of an oversized dump of UST to the pool from a trade

Table 2: UST pools on V2-style pools on block 15314735

Liquidity is usually not distributed uniformly in V3 pools. The price in the concentrated-liquidity pool would move to the boundary of the concentrated liquidity’s range, where LP’s supplied liquidity on the more valuable token is exhausted .

We found USDC-UST, and UST-WETH pools in V3 with different fees, as shown in table 3 below.

In general, these pools report a higher price for UST but with zero liquidity as the pool’s tick has moved to the tick spacing boundary. In our liquidity-weighted pricing formula, the product of ratio and liquidity becomes zero, resulting in no impact to the price of USDC and WETH.

The selection for Ring 2 tokens is much easier than Ring 1. Ring 2 is a “connection” between the Ring 1 tokens and the Ring 3 tokens. Ring 2 tokens is directly priced by Ring 1 stablecoins and it forms trading pools with other tokens.

For Ethereum mainnet, ETH is the obvious choice for Ring 2 because it can be priced with stablecoins only, and it has been often chosen by DeFi protocols to form trading pairs to their issued tokens. This has been illustrated in Figure 1 earlier.

Ring 2 currently only has a single token, but this could change. We recently found that some tokens (e.g. BTC2x-FLI) are only priced against WBTC. There is a case for including WBTS in Ring 2.

When Ring 2 contains more than 1 token, it will have to be extended into what we are calling Ring 2+. This implementation works as follows:

First, we use WETH-DAI/USDC/USDT pools to determine the price of WETH.

Second, we use WBTC-DAI/USDC/USDT/WETH pools to determine the price of WBTC.

Third, Ring 1 and 2 tokens are used to price tokens in “Ring 3”, e.g. token X is priced from pools of X-DAI/USDC/USDT/WETH/WBTC.


In summary, we expand the allowed number of tokens in Ring 2 from 1 to multiple with a new name, Ring 2+. The price of the tokens in Ring 2+ are determined one-by-one, in the order of liquidity dependencies. The first token in Ring2+ needs to be priced using only the Ring 1 stablecoins. The other Ring 2+ token can be priced using the Ring 1 stablecoins and the other Ring 2+ tokens. With more Ring 2+ tokens, we expand the number of tokens which can be priced as long as they form liquidity pool(s) with any Ring 2+ tokens. This idea is illustrated in the figure 2 below. Because there is only one token known to be priced with WBTC pricing, we have not yet implemented this idea.

Figure 2: Ring 1, 2+, and 3 tokens as an possible update to Credmark’s pricing 

We discussed how we selected the tokens for Rings 1 and 2 in order to make our DEX-based pricing algorithm work.

We also discussed how Ring 1 was resilient in the face of a depegging event.

 of the model is part of our open source repository of models 

 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.

Token Selection for Rings 1 and 2

Credmark’s DEX Pricing Model

As a veteran DeFi protocol, Uniswap v2 did a great deal to introduce the world to the idea of incentivized liquidity provisioning on decentralized exchanges. Liquidity in this context refers to a pair of tokens that are added to a pool so users can swap one of those tokens for the other.

While Uniswap v3 has overtaken much of v2’s market share, v2 remains active. It is still active on Uniswap and was forked to create SushiSwap and other decentralized exchanges (DEXes). Liquidity providers (LPs) still like v2 pools because of their simplicity. Some tokens only have v2-style pools.

LPs are rewarded for providing liquidity. Swaps generate fees that are shared pro rata amongst the LPs. Unfortunately, these fees are simply added to the LP’s position (which changes as tokens are swapped). This is called “impermanent loss.” The LP’s withdrawable amount changes with the price in the pool. which is only realized during withdrawal. Hence, the fees for V2 are not directly separatable. LPs may want to distinguish between the two in order to track their performance, or they may need to report them separately to a tax authority.

In this blog post, we propose a method for computing an LP’s fees.

The LP receives newly-minted LP tokens. The number of LP tokens is determined by the ratio between the newly added liquidity and the current pool’s liquidity.

For every transaction, 0.25-0.30% of the trade value is given to the LPs of the pool, pro rata. This fee, however, is not set aside. It is added to the LPs’ liquidity.

When LPs redeem their LP tokens, they receive a portion of the pool proportional to the LP tokens in existence at that time.

v2 is a constant product market maker (CPMM). It uses the product 

 of the amount of two tokens as the invariant for exchange. 

For a v2 pool with two tokens, a pool of reserve 

(1) The pool’s price ratio is also related to the reserve 

(2) When adding liquidity, the added token 

 is approximately, if not exactly, in proportion to the pool’s reserve 

 at a specific block number. The approximation is due to the fact that a swap transaction that changes the reserve can take place in the same block as a transaction to add liquidity.

(3) The deposit tokens represents the below amount of liquidity 

(4) The LP can withdraw tokens in the below amount based on the liquidity 

 added earlier, and the current ratio. The difference between the values, calculated using the current prices, in 

 is the impermanent loss. We need to note that the liquidity for the LP is not tracked by the pool; instead, we obtain it by (4).

 does not count when the fee is calculated. The amount the LP receives depends on the number of LP tokens redeemed.

Remember that when depositing tokens, the LP receives a number of new LP tokens proportional to the existing liquidity in the pool.

(6) We combine (7) with (3) to take into account the possibility of the pool’s reserve changing in the block in which the liquidity is added. At this point we resolve the ambiguity (approximation) in (3) and select the minimum values for x and y. This gives us the number of LP tokens sent back to the LP.

(7) When redeeming tokens, the LP gets a fraction of the reserve which is determined by the ratio of LP tokens redeemed to the total number of LP tokens. This amount is inclusive of the transaction fees.

(8) If we then exclude the value that would have been withdrawn without a fee (see impermanent loss calculation (5), we are left with the fee itself.

pool 0xB4e16d0168e52d35CaCD2c6185b44281Ec28C9Dc of USDC-WETH.

User 0x18196A32F99bD5feeAfd6bD6b55a63A0EeEf23a6 made 5 deposits and 1 withdrawal in full. We have a transaction balance table for the LP tokens.

The table below shows the LP tokens being minted and sent to the user, and finally the user redeeming the LP tokens.

Each row represents a transaction for which we can calculate the following fields:

: the amount of USDC and WETH available to withdraw using formula (8) from the total balance of LP tokens belonging to the user.

: the amount of USDC and WETH in the current transaction.

: the amount of USDC and WETH that is available to withdraw (excluding fee) using formulas (4) to obtain liquidity with token0_lp, and token1_lp from the previous row, and formula (5) which takes into account the change in token prices, which is reflected in the pool’s token ratio.

: we apply formula (9) to the above result. This is the fee accumulated between the block numbers in the previous row and the current row.

 = token0_lp - in_out_amount0 - token0_lp_current

token1_fee = token1_lp - in_out_amount1 - token1_lp_current

Using this method, we only need to fetch LP token balances to derive information about the tokens added to the pool. We can therefore avoid fetching more detailed transaction data about these underlying tokens. We want to do this for two reasons:

LP tokens can be swapped among users, likely close to a fair price that is inclusive of the fee. There is no funding token transaction for a user who buys an LP token. In our method, we count the fee for the buyer of the LP tokens from the time of receipt.

The funding/redeeming transactions can be confused with swap transactions. Locating only the transactions for LP token simplifies the data preparation.

The result shows that we can restore the actual amount of funding tokens in close approximation.


https://etherscan.io/tx/0x04bc2b59ebec879a6b9b93be11dcf9707e1fae389639ca15227cdcc9f75f7634

: 47.283594 / 0.03903517202 exactly match with 

https://etherscan.io/tx/0x2411f4a563db5a3c737f03bc29371ab3d6c79c68d174d73bd7e912c81f2455dc

https://etherscan.io/tx/0xc5093125f5417c52de95ad268f22f54d404295b08b17e5089100c916ee9b2b4d

https://etherscan.io/tx/0xbcd49c3006e544aa5c0b1e9df53a827ae9e739109c92f98957a5902e83eb9bfc

: 99.99994258 / 0.07826888671 closely matches with 100 / 0.0782688416 

https://etherscan.io/tx/0xdbad8b3233cdeaeff7e79e18a15c6931d4d22afda016e44e287538d86fe67bd6

: -297.2393642 / -0.2343857018 exactly matches with 

https://etherscan.io/tx/0xb308f679cfb5d6e5918ad4091a5403676c0909aedc897b23b8a37de52b64df77

The total fee for this LP is the sum of fees from all block ranges, USDC 0.428541381 and WETH 0.00034724257, for a total investment of $600 worth of USDC-WETH.

In this blog post, we described our method to calculate the current fee due a Uniswap v2 LP –including an LP who bought LP tokens from another party – at any point in time. We do this without requiring information about the original token deposits.

This output can be generated by running the model uniswap-v2.lp-fee-history by calling the script below:

The last row is added by the model in order to show the block number at which the model ran. It is not a transaction record.

 around the globe and across industries.

Our 

Fees from Liquidity Providing

Computing LP Fees for Uniswap v2

Vineet’s Model Spotlight blog series is designed to highlight models deployed on the Credmark platform. Some will be highlighted because they’re generally useful, some because they are complicated and require some background, and others simply because Vineet finds them interesting.

These models are developed using the Credemark Model Framework (CMF). Model concept and reference docs are available 

 is defined as the amount of a token transferred into an account and 

 is defined as the amount of a token transferred from an account. 

 is the difference between inflow and outflow over a period of time.

For example, if 100 ETH were sent to an exchange account address and 150 ETH were withdrawn that day, then the NetFlow is -50 ETH indicating a net reduction in the on-exchange balance of ETH.

If the NetFlow value is above 0, it indicates that the volume of the token flowing into the account is greater than the volume that has flowed out of the account. If the value is below 0, it indicates the opposite.

NetFlow can provide valuable insights into the movement of funds within the cryptocurrency ecosystem. By tracking the flow of funds in and out of a wallet, users can gain a better understanding of how their own transactions fit into the larger picture of cryptocurrency usage and adoption.

The flow of funds can also be useful for identifying trends and patterns in cryptocurrency usage, such as which coins and tokens are gaining or losing popularity, which exchanges or platforms are being used most frequently, and which addresses or entities are the most active in terms of transactions.

This model takes 4 parameters: address/symbol, netflow_address, window & include_price.

Token “address” and “symbol” are case insensitive.

You can find the list of Credmark-supported symbols in the 

Including price increases the latency of the model. For quicker response set include_price to false.

Window value with multiple units like “1 hour 30 minutes” is not supported. Use the single value for the window, i.e. “90 minutes”.

This model outputs NetFlow, inflow, and outflow. It also includes the price value of each if not disabled explicitly in the input.

The best way to understand how to use a model is by example. Here are three.

Example 1: Get Staked AAVE’s NetFlow of AAVE for the last week

In the output above, you can see that the model ran at block number 16333134 which was the latest block available at that time.

Staked AAVE’s NetFlow from 1672227011 (Wednesday, December 28, 2022 11:30:11 AM UTC) to 1672831799 (Wednesday, January 4, 2023 11:29:59 AM UTC) is approx 32,976 AAVE valued at $2,214,526.

Last week, $2.6M worth of AAVE was staked (inflow_value_last) and $0.4M worth of AAVE was unstaked (outflow_value_last). As the NetFlow is positive, we can conclude that a lot more AAVE is getting staked than unstaked.

Example 2: Compare Uniswap V3 ETH / USDT (0.05%) & USDC / USDT (0.01%) pools’ NetFlow of USDT for 2022

ETH / USDT (0.05%) pool’s contract is deployed at 0x11b815efb8f581194ae79006d24e0d814b7697f6

USDC / USDT (0.01%) pool’s contract is deployed at 0x3416cf6c708da44db2624d63ea0aaef7113527c6

Since we need to run the same model but for 2 different inputs, we can use the compose.map-inputs model to get the results in a single request. It is a utility model which runs the same model for a list of inputs.

We need to get NetFlow for 2022, so we’ll run the model at block number 16308189 (Dec-31-2022 11:59:59 PM +UTC) with a window of “1 year”. We can speed up the model by excluding price as USDT is stablecoin and we can assume its price to be $1. In order to do that, just set “include_price” parameter in the input to “false”. Despite the very large amount of data needed to run this model, it typically executes in 25-30 seconds.

In the result above, you can see the outputs for each pool. As we set include_price to false, the price values in the output are returned as “null”.

ETH / USDT (0.05%)’s NetFlow of USDT is approx 7M

USDC / USDT (0.01%)’s NetFlow of USDT is approx -95M

This indicates that USDT reserve of the USDC pool has decreased by 95M and ETH pool’s increased by 7M. The ETH pool performed magnitudes better than the USDC pool last year. Does it mean the ETH pool is a better investment opportunity for 2023? I am leaving it to you to figure out. Let’s move on to the next example.

Example 3: Find the amount of DAI minted and burned in the last hour

Many of the tokens that you come across have a fixed total supply, but for some tokens it is variable. Tokens are burned and minted.

The amount of burning and minting of a token can be interesting because it can provide information about the overall demand for the token, which can be used to make trading decisions. If burning is happening, it could indicate that the token is becoming more scarce, which could lead to an increase in its value. Conversely, if minting is happening, it could indicate that the token's value is decreasing, which could lead to a decrease in its value.

One such token is DAI, a stablecoin by MakerDAO. DAI is minted when users borrow against locked collateral, and it is burned when loans are repaid. We can use this NetFlow model to track the minting and burning. When a token is minted it gets transferred from the ZERO address (0x0000000000000000000000000000000000000000) to the receiver and vice versa when the token is burned.

Let’s run this model for the ZERO NetFlow address.

In the output above, the model ran at block number 16333284 which was the latest at the time of running the model.

inflow_scaled is the amount of DAI transferred to the ZERO address, i.e. the number of tokens that were burned. outflow_scaled is the amount of DAI transferred from the ZERO address, i.e. the number of tokens that were minted.

 in the last hour, a NetFlow of 3.5M DAI


Vineet's Model Spotlight

token.netflow-window

Spam tokens. They’re horrible, and they’re everywhere¹. They just show up in your wallet. And there’s nothing you can do about it since anyone can send you tokens without your permission.

Sometimes these tokens are designed to get you to visit a website, for example, a token called UniswapLP.com. (⚠️Don’t go there!)

Sometimes they’re designed to confuse you, e.g., a token named “AAVE” which isn’t the AAVE token. Why would someone do that? Usually to steal your real AAVE tokens.

Sometimes these “free” tokens are part of a larger pump-and-dump scheme. They aren’t nefarious to you, they’re just annoying.

In their aim, spam tokens are just like spam emails.

Most people rely on centralized providers to process their email. For example, if I use Gmail (owned by Google) to send my mother a message to her Hotmail account (owned by Microsoft), two companies with large R&D budgets get the chance to review my email to decide whether or not it’s spam. If Google decides it’s spam, it won’t even send it on to Microsoft. If Microsoft decides it’s spam, it may reject it or, out of an abundance of caution, put it in my Mom’s spam box instead of her inbox.

This all happens without most of us even thinking about it. Yes, the system inevitably marks some legitimate email as spam, but, on whole, it does a good job of keeping huge amounts of junk out of inbox. In addition, email clients let users mark spam email that made it through the filter.

Crypto is peer-to-peer. When someone sends you a spam token, there are no organizations with large R&D budgets processing the transaction. It’s direct. That’s the beauty of crypto.

That’s also the reason we can’t avoid spam tokens. They show up in our wallets, whether we like it or not.

When spam email ends up in your spam box, our email provider isn’t eliminating it. Instead, it’s hiding it so that you won’t see it unless you go looking explicitly. This can be frustrating, and often confusing, even for those of us who know exactly how the process works.

Hiding spam tokens can be equally confusing, if not more so.

But before we can talk about hiding spam tokens, we need to take a little detour to make sure we’re all on the same page. We need to understand where we might come across these spam tokens in the first place.

A wallet is a piece of software or hardware that holds public and private keypairs². These are a bit like username (public), password (private) pairs that give you access to something like your bank account. One critical difference is that a public/private key gives you ownership – not just access – to blockchain addresses that “store” your tokens.

A crypto wallet also holds the list of addresses owned by your public/private keys. This is why we decided to call wallets “wallets” even though they aren’t wallets like the one you carry around in your purse. Sometimes analogies help, but In this case, the analogy is confusing! Nonetheless, it’s the term everyone uses, so I’ll stick with it.

If you’ve spent any time in crypto you are no doubt familiar with various types of wallets. We have browser-based wallets like 

. And finally we have wallets stored at institutions like 

, which aren’t wallets at all. Those “wallets” are accounts, just like your bank account.

If you have a wallet you can see its contents, i.e., the tokens stored at one or more addresses managed by the wallet. But it turns out that there are other ways of seeing these tokens.

A wallet lets you explore the tokens (or transactions) associated with an address. But other software does as well. Addresses, after all, are public, as are all transactions associated with those addresses

I lump all of these non-wallets into a category I call “Transaction Explorers”. This class of software is mainly aimed at three categories of people:

Developers tend to be happy with relatively crude interfaces that allow them to see as much data as possible. In Ethereum, the most popular explorer is 

. Copy paste an address into its search bar and you can see every single transaction associated with it. Try it with one of Vitalik Buterin’s addresses: 

0xab5801a7d398351b8be11c439e05c5b3259aec9b

. You’ll be amazed by the volume of spam he has to deal with!

Traders like to know what they have. A popular tool for DeFi degens is 

. It does a great job of showing you what you own and how much it’s worth. Again, try it with 

And finally we have “serious” tools for accountants. These things are thorough and approach the problem from a completely different perspective. They don’t bother showing you a picture of your latest NFT purchase, but they do things like calculate the rewards you earned on Uniswap. Why? Ask the taxman. Our favorite explorer in this category is 

Wallets and transaction explorers are the equivalent of your email client: Gmail, Superhuman, Apple Mail, Outlook, etc. We use these email clients to send email to other email clients, but, as I mentioned earlier, that process depends on large corporations with the means (AIs) to deal with spam. In a peer-to-peer world, that isn’t possible.

This means that spam detection and spam processing are the responsibility of each wallet or transaction explorer. Everyone has to roll their own. Let’s look at three different approaches used in the industry:

This is the approach taken by the MetaMask wallet. Tokens must be approved (“imported”) in order for MetaMask to display them. This is a great strategy for people who understand what’s going on but it’s very confusing to new users.

If, for example, I send you a token that’s never been imported into your MetaMask, you won’t see it. To make matters worse, the approval process is complicated. You need to know the token’s contract address. And who knows where to find that?!

This is the most common approach. Show users all the tokens at an address. That’s what Zapper does, and no one seems to mind.

Some users deal with this problem by sending spam tokens to addresses setup for this very purpose. 

 is a good example. The only problem with that is that you spend gas getting rid of your spam!

This is where we get into interesting territory. There are currently three approaches being used to identify and manage spam tokens: home-grown application level strategies, user flagging, and centralized repositories of spam token addresses.

Some wallets and transaction explorers are coming up with their own internally-developed heuristic to generate a whitelist or blacklist of tokens that is then used by their applications.

 for example. Whether this list is algorithmically generated, hand-curated, or some combination isn’t relevant. What matters is that many projects are re-inventing this wheel, because blocking or hiding spam is so critical to the user experience.

When a wallet or transaction explorer notices a spam token, she can mark it as spam and the software hides it. This allows her to manage her own universe of tokens. Unfortunately, this puts the burden on a user who may not know enough to determine whether or not a token is spam. As I mentioned, sometimes spam tokens have the exact same name as legitimate tokens. If you have two AAVE tokens in your wallet, which is the real one? Even for a knowledgeable user, this technique only works well as long as the volume of spam is manageable.

An alternative to end user flagging is crowdsourced flagging. Etherescan runs a project to support this: 

https://info.etherscan.com/etherscan-token-reputation/

. Both are a good resources for anyone having to manually mark their spam tokens.

What if we had a collaboratively-developed source of token legitimacy, accessible by either a website like Etherscan’s or API? That the information could be used by developers so that they didn’t have to reinvent the wheel or place the research burden on their users?

It would be fantastic for the entire crypto industry. Unfortunately, it doesn’t exist yet.

Luckily Credmark is working on this problem and plans to put a proposal forward in the coming weeks. We’re hoping to make it the best of all worlds: decentralized, open source, and collaborative. It’s an ambitious goal, but the industry needs it, and we have the infrastructure to support it.

¹ In 2022 alone, Solidus Labs estimates that over 120,000 scam tokens were deployed: https://www.soliduslabs.com/reports/rug-pull-report.

Credmark Blog

For the latest technical analysis, partnerships, and community updates