My name is Peter and I recently joined Credmark as a Senior Data Engineer.

My undergraduate degree was in economics but I quickly pivoted into the tech space early on in my career. I got my Master’s degree in Data Science and it was through this program that I discovered Data Engineering. I was previously a Data Engineer at a startup where I created a Data Warehouse from scratch, built and maintained serverless data pipelines, and even dabbled in some DevOps work. Most recently, I was a Data Engineer consultant where I got the chance to build data pipelines for a lot of different companies from startups to major national e-commerce companies.

I first learned about Bitcoin in late 2016 from my mom of all people 😂. I started researching everything about Bitcoin and Ethereum and it became clear to me that this technology was going to radically change the world. Having smart contracts that could enable true peer-to-peer transactions in a decentralized, censorship resistant way was a very powerful idea. As I mentioned above, my undergraduate was in economics and my career has been in tech. Crypto is the convergence of those two disciplines so it was naturally a perfect fit for both my skill set and my personal interests.

As exciting as crypto was in 2017–2018 there was still no “killer app” that existed then to really showcase the power of crypto. It wasn’t until the DeFi boom in 2020 where I think crypto “killer apps” emerged that showed what could be created with smart contracts. I think DeFi has already shown that not only can it deliver on some of the promises of peer-to-peer transactions, but it can replace and outperform many of the same counterparts available in traditional finance all while being permissionless and open source for anyone all over the world to interact with.

I see DeFi as both a technical and financial revolution and I am excited to play a small role in helping to further the movement.

As a fellow DeFi degen, I find that the space is currently missing some basic risk metrics that are ubiquitous in the traditional finance world and that help investors gauge the level of risk associated with any investment. I love that Credmark is trying to bring these risk metrics to DeFi and doing so in an open and permissionless way and believe this data is a pivotal missing component for the space which will help attract more investors who may currently be turned off by the lack of clarity on the risks involved in DeFi.

My goal is to build a robust, open source data pipeline that can allow us to take a look at many DeFi protocols and compute risk metrics so that these can be incorporated into risk models and made available to all investors in DeFi. I want all investors to have a full picture so that they can properly weigh the risk and rewards of every investment decision in DeFi.

Success means, in the future, anyone will be able to help run and maintain data pipelines that deliver vital risk metric data for all major DeFi protocols.

Introducing Credmark’s Senior Data Engineer

From October through November of 2021, Credmark ran a hackathon looking for the best Uniswap v3 recommendation model on the market.

Even a cursory glance shows that uni v3 is not profitable without active rebalancing or a larger strategy

Uniswap v3 is seen as an undesirable product for retail since the barrier to entry, and position management overhead is quite high for a retail user. Although the capital efficiency is higher, determining the ranges in which to invest in a pool pair is another mountain to climb in itself. Having a recommendation model which suggests ranges and being able to see an estimated profit of the used strategy via simulation can give users a bit more confidence when providing liquidity to overcome the low rate of profit in many pools in Uniswap V3. The less volume, the lesser the fees for liquidity providers.

Taking a huge step in this direction we were using a Bollinger strategy for assessment in our Smart Pool and using our in-house Uniswap V3 Strategy Simulation Engine which gives an estimated APR for the strategy. This allows a user to understand the risks/profits for their assets in a more confident manner. But the APR numbers were not impressive enough.

Credmark’s Uniswap V3 Hackathon created a community of modelers for such cases which allows the developers to contribute to the mission of lowering the entry barrier to many complex protocols for a user.

And the community has proven us right. We are proud to announce that the winning model for our hackathon has outperformed our base Bollinger model. The level of sophistication shown by the winner in model development is impeccable. We are going to use this as our new base model in our smart pool application. This will allow us to highlight the work of our community and provide it a platform to be able to use retail users which can give them a huge advantage in making their decisions.

The top 7 model results can be found here:

And the winning model’s performance over a 4 week period of time can be found here: 

https://docs.google.com/spreadsheets/d/1sp5aPoHLnEQBReOLgGPqxYBHC8SYoQti7G2e5oOR5C4/edit?usp=sharing

More details regarding the competition can be found here: 

More importantly, below is the detailed technical document describing the strategy used by the winner. The following documentation is provided by the winner, demonsword, themself.

The purpose of the model mentioned below if to improve the accuracy of the prices of crypto currencies predicted by computers. In general, Bollinger is used for price prediction but it uses previous prices for a certain amount of time (for example 7 or 8 days). But LSTM as the name suggest remember changes for a very long period of time.

Long short-term memory (LSTM) networks were invented by Hochreiter and Schmidhuber in 1997 and set accuracy records in multiple applications domains.

Around 2007, LSTM started to revolutionize speech recognition, outperforming traditional models in certain speech applications. In 2009, a Connectionist Temporal Classification (CTC)-trained LSTM network was the first RNN to win pattern recognition contests when it won several competitions in connected handwriting recognition. In 2014, the Chinese company Baidu used CTC-trained RNNs to break the 2S09 Switchboard Hub5'00 speech recognition dataset benchmark without using any traditional speech processing methods.

The scope of LSTM is very huge as it can be used in Robot Control, Time Series Prediction, Speech recognition, Rhythm learning, etc.

But right now, we have fixed our scope on only time series prediction as the problem statement given to us is the perfect example of time series prediction. The model that I have made takes minimum six days data and can predict the data for next five days.

The only thing that we are predicting is the open and close price of crypto and then dividing it in three tiers. The model at least need data for six days to predict the prices for next five days not less than that.

For the prediction of prices, I have used three LSTMs. One LSTM is used to predict the max price of each day. Second one is used for minimum and the third one is used for median.

And on the basis of these three values for each day and the standard deviation I have calculated the prices for each and every tier.

First thing that I have done is to divide the dataset in three parts. One containing the maximum price of each day. Second containing the minimum price of each day. And the last containing that price of each day which are closer to median of that day.

Then I have to convert this time series problem into supervised problem in order to make it suitable for LSTM. So, I have used shifting for this process. And I have to shift the output of LSTM in order to get the prices of the future dates.

Now with the help of these prices I have designed an algorithm which will give ranges according to the tiers (High Risk, Medium Risk, Low Risk).

In general, there are eleven classical methods for solving time series.

Autoregressive Integrated Moving Average (ARIMA)

Seasonal Autoregressive Integrated Moving-Average (SARIMA)

Seasonal Autoregressive Integrated Moving-Average with Exogenous Regressors (SARIMAX)

Vector Autoregression Moving-Average (VARMA)

Vector Autoregression Moving-Average with Exogenous Regressors (VARMAX)

Holt Winter’s Exponential Smoothing (HWES)

For details about these methods you can check out this link:

https://machinelearningmastery.com/time-series-forecasting-methods-in-python-cheat-sheet/

But all these methods have one shortcoming that they cannot remember the trends which are way before in the past. And this problem can be solved by the use of LSTM. That’s why I have used LSTM for this problem.

First thing in any model is to prepare a dataset for your algorithm.

There are some columns in the dataset that have no need for the algorithm. Those columns are id, timestamp, timestamp1 and indexes. Next thing is to divide the dataset in three parts. For that I have collaborated all data entries according to datetime and from each group I only pick three entries first one is minimum, maximum and median of amount0 and add these entries in three different datasets.

After this we have to prepare the dataset for LSTM. This involves framing the dataset as a supervised learning problem and normalizing the input variables. We can use the shift() function in Pandas to automatically create new framings of time series problems given the desired length of input and output sequences.

This will help us to combine six rows combined to one row and converting this 11 columns dataset to 66 columns dataset. With these columns we have 5 more columns which will have the future token prices for next five days.

Now we can define and fit our LSTM model. We will define the LSTM with 50 neurons in the first hidden layer and 5 neurons in the output layer for predicting pollution. The input shape will be 6-time steps with 11 features. We will use the Mean Absolute Error (MAE) loss function and the efficient Adam version of stochastic gradient descent.

Now after this I have got the result in the normalized form. So, I have to un-normalize it. After unnormalizing it the work is still not complete. We will understand it with the help of an example. For example, we have the input of 10 days. So, input will be in the form of:

[ 1 2 3 4 5 6]
[ 2 3 4 5 6 7]
[ 3 4 5 6 7 8]
[ 4 5 6 7 8 9]
[ 5 6 7 8 9 10]

the numbers represent days in this matrix.

[ 7 8 9 10 11]
[ 8 9 10 11 12]
[ 9 10 11 12 13]
[10 11 12 13 14]
[11 12 13 14 15]

From this linear matrix I have to take only last five values as they are the only values associated with new days [11 12 13 14 15]. Now I have got minimum, maximum and median values for next five days.

Our next task is to create price ranges on the basis of three tiers. For that we have calculated standard deviation of all three datasets. For low-risk tier open range will be minimum predicted value and close range will be maximum predicted value. And standard deviation is added or subtracted to one of the open and close which is closer to median in order to increase the range between them. For medium risk tier open will be minimum range and close range will be maximum range. And for the high-risk tier standard deviation will be added or subtracted to the minimum or maximum which is farther from median in order to decrease the range. This will be the end of the model giving the prices of three tiers.

One of the main assumptions is that the current information has a dependency on previous data. This dependency is very important for the data.

LSTMs are sensitive to different random weight initializations

The input format will be the one given in hackathon. I have created a function named “convertinputformodel” which will take csv as input and return six things three matrices according to minimum, maximum and median and datetime for all three.

The output format of the model will be the prices of the next five days of the input . And then we have created price ranges of three tiers. As discussed in Model Methodology.

For Testing I have defined a term known as hit-ratio. Hit ratio is defined as the number of times price of token lies in the open-close range divided by total number of times tried.

 = price lies in open-close range / Total tries

As in many financial markets the price stays relatively stable and we can benefit from the multiple predictions provided by model for a particular day by taking average of them.

Uniswap v3 Hackathon Deep Dive

This past year has been the most rewarding, challenging, and exciting year of my life.

In January, after more than 2 years working on on-chain credit scoring as CTO, it was clear that Crypto was lacking the fundamental data and risk building blocks and I set out to fill those gaps.

In February, I took over as CEO of Credmark and decided that the future of risk was decentralized. I started to plan out what that would mean, and how to build a team.

In March, people caught wind of my plans, and before long, I was having conversations with investors. The appetite for DeFi risk data was substantial; VC’s were eager to invest in the project on the strength of Credmark’s previous work alone. I had earned the credibility through years of pavement pounding and finally had the resources to build a world class team.

I spent April onboarding (or in some cases, re-onboarding) my founding team and writing our 

. The Whitepaper was critical in clarifying my vision since Investors were eager to get in before we had a prototype. Drafting allowed me to think about the skillsets I would have to hire for to build the project.

, and got the wheels turning on releasing the token, CMK.

We wanted to get the token out quickly with the following assumptions:

A first-mover fair launch using Uniswap v3 would would grow a community of engaged experimenters to the project

The long bull market would turn around soon, and launching would become more difficult with time

Since we had runway, Credmark owning it’s liquidity was more important than cash

With that in mind, we set out planning the launch. Uniswap v3 was about to launch and seemed like a perfect candidate to use for an 

. I studied the documentation Uniswap released on the newest iteration of their protocol and saw immense opportunity to fair-launch on the platform. We would be the first token ever to launch on Uniswap v3, an experiment in creating a fairer and simpler alternative to other IDO platforms.

In June, we launched the token. My desire to experiment and innovate created two problems: many people didn’t understand the mechanism, and thought that we were rug-pulling, rather than fair-launching (Since then Alchemist’s Copper has done similar launches with far better results). In the confusion, we lost some of the support of the community. Adding to our list of complications, the fear we tried to avoid hit; the 3 days of our token launch were some of the worst in the crypto markets in 2021. As a result, we weren’t able to rely on market confidence in order to help us with our goals.

While a less-than-flawless token launch was inconvenient, Credmark was founded to solve risk and data problems in DeFi. We needed to put our heads down and build: So we did.

In July, we used our existing knowledge of Uniswap v3 to 

. It was our Proof of Concept for how an application could use Credmark’s data in order to perform a DeFi function, and give retail DeFi users a tool that previously would only be available to institutions. The problem with concentrated liquidity is that without enormous amounts of capital (i.e. being a Whale), it has abysmal returns.

Our experience with SmartPool allowed us to refine our roadmap. We knew who we needed to hire, and go out into the market to better understand risk-management problems folks in DeFi were having.

August & September we continued to grow our team and set up relationships and partnerships. Our partnership strategy was to find DeFi projects that have risk exposure and determine whether tools like SmartPool, or the data driving it, could help. We established research, service, and data partnerships with 

In September we also finished up the base layer of our Data ETL. Originally our plan had been to buy, rather than build, a data solution. However, there was nothing available on the market sufficient to fuel a decentralized modeling platform. Clearly it was something that had to be moved in-house. While it extended our build timeline, I am very excited to be able to offer the type of quality data-as-a-service to other projects.

To prepare for our platform launch, we also established relationships with Market Makers and Centralized Exchanges. These relationships will drastically decrease the barrier to entry for acquiring CMK, a necessary component to interact with our platform.

October was spent building out our Platform. We decided to do the platform in 2 phases, the first is single sided staking with access to graphs of some of our Risk Primitives, VAR and LCR. The second is to add revenue sharing to the staking mechanism via our Data Platform Roles and a self-service API. We also released our 

 in October, a repository for our research and information about the DeFi landscape.

November saw the expansion of the risk library and the onboarding of the final members of our leadership team. It was also the opportunity for us to finish and test the first phase of the platform.

December was Credmark’s first On-Site in Austin TX, with Asan, our head of Risk and Research, Matthias, our head of Product, and Paul, our COO coming to town to spend time with myself, Emilie, Momin, Stijn, Joey, and Collier. We spent a week finalizing process and organizational structure as we grow from a small to a medium sized startup.

 at hand within the first 2 weeks, we’ve had over half a million dollars staked in order to access our risk metrics!

Here’s to growth in 2022 and making DeFi a safer, more deeply understood place!

Credmark 2021: A Retrospective

) as well as some insights into how we are building our own 

, we explored the outputs of the Credmark platform, with focus on the first 2 models we produced: 

This post will expand on the following questions:

How can these metrics be used in a composable manner with existing metrics (like TVL)?

Liquidity risk is the risk that a business will have insufficient funds to meet its financial commitments in a timely manner.

To measure this risk, we use a metric called liquidity coverage ratio (LCR). LCR is defined as the proportion of highly liquid assets held by an organization to ensure that they maintain an ongoing ability to meet their short-term obligations (cash outflows for 30 days) in a stress situation. It is one of the essential liquidity risk measures in traditional finance.

Value-at-Risk (VaR) is a model to measure market risk. VaR is a statistical measure used to calculate the maximum potential loss caused by market movement under business-as-usual circumstances.

It is defined as the maximum dollar amount expected to be lost over a given time horizon, at a pre-defined confidence level, given normal market conditions.

It’s important to note that this measure doesn’t provide any guidance on how much can be lost in a “black swan” type event, an unknown event with unknown probability.

VaR is commonly used in TradFi to calculate potential losses. By aggregating portfolio level VaRs organizations can understand the maximum potential organizational losses from market prices volatility and take a quantitative decision on risk, either by increasing capital reserves or moving into lower-VaR positions.

Because VaR is applicable to any group that holds assets subject to market fluctuations, it can easily, and usefully, be applied to DeFi protocols as a financial primitive.

For an in-depth analysis of the mathematical equation, please refer to the 

Both LCR and VaR are considered financial primitives in the investment banking world. They are well documented, widely accepted and trusted and their value does not need to be justified.

By establishing these metrics early on in DeFi we can accomplish 2 important things.

We can begin to bridge the gap between DeFi and traditional finance in a way that can lead to institutional money entering the ecosystem.

The addition of such capital would add much needed depth to available liquidity and add a sense of stability to the industry.

Additionally, by starting with such well documented models, we can focus on data integrity since the inputs for these models are well understood.

What are practical use cases for these metrics?

The most important implication of applying these models to DeFi is that we can confidently compare protocols in an apples-to-apples fashion that was just not possible in any significant or scalable way before.

While DeFi is touted as a permission-less, composable financial playground that offers flexibility and freedom in many ways, certain parts have lagged behind. In particular, risk assessment has become a major pain point for every type of persona (retail, DAO, institutional) and is generally done in manual, non-scalable manner.

If the technical infrastructure allows capital to flow quickly and efficiently, the lack of verifiable risk metrics is what is holding back DeFI currently.

By providing these risk metrics in a format that allows for massive throughput, efficiency in DeFi can fully leverage the immense technical advantage it has over traditional finance.

How do these models improve upon existing models in DeFi?

Currently, the most widely used statistical model in DeFi is Total Value Locked (TVL; sometimes called Assets Under Management or AUM).

This is a useful metric to get a surface level idea of a protocol’s health, it is very flawed as a risk management metric. Many protocols show impressive TVL’s as savvy investors ape in to claim high yields and then pull that liquidity out as soon as they reap the early benefits.

Or, TVL can be propped up by an extremely volatile asset that is particularly vulnerable to market movements. VaR and LCR don’t solve the entire equation, but they offer more insight than TVL.

When you combine VaR with TVL, you get a more complete picture of what you’re getting yourself into as an investor as you can compare protocols apples-to-apples. High TVL might mean a good price for governance tokens and consistent return on deposits, but a high VaR and insufficient LCR means that one bad market move and you could be locked out.

If that same protocol has buffered their reserves appropriately, they can have a high VaR without fear of becoming insolvent. This then allows the TVL to realize the upside of volatile assets and the LCR protects the retail user.

It might not have too much visibility but the main focus for us is data. It is in line with our strategy of the state-of-the-art highest quality data readily available to our community. In the near future we’d like to have a diversified portfolio of market and account behaviour information.

Using VaR makes sense as this is a well-known metric but using traditional finance parameters for crypto might not be the perfect solution. Hence we are planning to develop crypto native parametrization of VaR. Also we are planning to cover more products, in particular add VaR for Uniswap LP positions.

Having behavioral data should help us to further refine LCR calculations. We’d like to expand our analysis on liquidity in stable coins.

Investment metrics are another important goal that we plan to further expand in the short run. So there is a lot to come.

Credmark Risk Models: Part IV

We now take a look at the data ETL portion of our platform. This post will illustrate the following points:

The types of data we are currently working with,

Our competitive landscape and how we differ,

How we are approaching the decentralization process of our ETL,

How we plan on delivering data to our growing community of engineers, scientists and developers.

Why Credmark is building out its own data ETL

Credmark is a DAO and intends to service the DAO-to-DAO business model with data available in a permission-less manner.

At the core, we are a data company; so relying on 3rd party data is risky and unreliable. Throughput will be high on our platform, and our past experience working with 3rd parties has led to less than desirable results. If our data provider were to go down and we are unable to address the issue, we lose credibility as a reliable source of data. Using 3rd parties for data leads to issues on throttling, security risks, and deploying additional resources dedicated to managing that external relationship.

Additionally, situations like disaster recoveries will be hard to address when direct access or the management of the data infrastructure is unavailable.

There is also a matter of methodologies and by extension, scalability, when working with 3rd parties. In order to really trust 3rd parties for data that fuels the core of your business; you need a solution that has business viability, high uptime, SLA’s, extensive documentation, and high throughput. We’ve found all of this to be lacking with the current providers on the scene.

Blockchain data is public, so it was rational to extract the data ourselves.

We have been working hard to build our data ETL. However, it’s not ready for public use just yet. To allow for us to work on a few projects in parallel, we’ve leveraged The Graph for the current iteration of our 

. In the next few months, we’ll be swapping out the data backend for our own dataset derived from on-chain data. Even when our initial dataset is complete, we’ll still leverage other data providers for research that fuels the risk library content.

, to export the blockchain into a data lake. We wanted to avoid using SQL based databases since those do not scale well, so we chose to export it into an AWS data lake.

1st order data is raw so it’s either in number or hex values which makes it unreadable for most people.

Leveraging the Athena service, we can then convert this data into queryable data. Still raw, but slightly more organized.

Our 2nd order data is basically 1st order data combined with ABIs from smart contracts so it is human readable and interpretable.

An ABI is essentially a filter that can be applied onto raw data to make sense of the data. It allows us to understand what each function does in order to add context to each transaction.

Other organizations in the same field started out with Postgres, whereas we chose to use 

. It provides efficient data compression and encoding schemes with enhanced performance to handle complex data in bulk.

Postgres requires more centralized maintenance in regards to storage and computing power; and is difficult to migrate. Normally, you’d have a DB admin to maintain, optimize, and migrate relational databases. Now, centralized providers like AWS exist and offer managed relational databases. However, this still requires some maintenance and still has the difficulty of: moving data around, adding and removing rows and columns.

To Credmark, this does not sound like a properly structured decentralized infrastructure. We chose to start by using tools that are server-less and not hosted on a single (or cluster) of managed servers. This choice allows us to automatically scale our storage and throughput to our needs.

We’re not fully decentralized yet, but we designed our infrastructure to be easily migratable from the very start. That is why we started with tools that are server-less and aren’t required to be in a specific data storage.


For the blockchain export, we are using existing Amazon services so we don’t have to manage servers ourselves. We are leveraging auto-scaling groups with EC2 instances in order to export data from Ethereum ETL into Amazon S3 (simple storage) using the AWS Data Pipeline.

The data is first stored as CSV data. We need to convert this to something more queryable. CSV’s are not efficient when looking for specific data. We can leverage AWS Glue in order to convert the data from CSV into Apache Parquet files which are also stored on the S3 storage buckets. Parquet files are in a columnar format which allows us to query specific columns as opposed to the whole file making querying faster, cheaper and more sustainable.

In the future, we want to leverage containers for people to help with the computation workload. These would be Credmark ‘nodes’.

With Apache Parquet, we can store it anywhere that we can save files. Later, we can shift to other data stores like blockchainDB or IPFS.

We are a Big Data company that wants to decentralize, and we want to share our experiences and discoveries along the way.


What developers and engineers can expect from the Credmark platform

On the road to becoming a DAO; we are continuously encouraging our community to voice their opinions, their skill sets, and their ideas so we can build the platform to fulfill our community’s needs. To that end, we’re also working with a team of engineers and analysts to see what they like to work with and how they like to process this kind of information.

Currently, our platform has graphs and charts for individuals who are concerned about data, but don’t know how to use data.

We are also in the process of building out API access for developers and engineers who want to consume the data that is currently viewable in the web platform.

In addition, we will have various data formats for data analysts/scientists to consume; but we need your input to make sure we’re doing it right! If you are a data enthusiast or developer/engineer, please share with us how you work and what you like to use.

Credmark Data ETL: Part III

Staking converts CMK to xCMK proportional to how much CMK is owned by the contract.

Unstaking converts xCMK back to CMK, with issued rewards.

Every 8 hours that elapse between either staking or unstaking the contract issues rewards via the rewards pool.

Any mechanism that generates CMK can be issued to xCMK holders simply by transferring CMK to the contract. This keeps revenue sharing very simple.

We’re starting our rewards pool with 100k CMK issued over 36 days. This allows us to adjust any issues we may encounter during the first month, and re-evaluate the strategy early in the protocol life cycle.

If there are no issues, we can repeat the rewards at the same rate to achieve 1M CMK annually. This emission rate would allow Credmark to issue continuously for 33 years, before revenue.

xCMK broadcasts an instantaneous relative value (with respect to CMK). This makes xCMK a poor choice for non-oracle or non-TWAP collateralization due to the potential for large amounts of capital to pump CMK while lowering the relative ratio of xCMK to CMK. Consequently, collateralization of Credmark tokens are recommended for use with CMK, rather than xCMK.

Static Analysis tool Slither issued warnings about performing logic based on block.timestamp (Mythril didn’t issue any). Since Rewards Pool is a time-based contract, this was a necessity. We have been informed by auditing firms that using block.timestamp in production code is not a problem. My understanding is that as long as you aren’t operating on a time-sensitive price, which the contract doesn’t do, this is reliable code. See 

Like all DeFi contracts, this is decentralized code. As such Credmark cannot retrieve digital assets lost due to user error or undiscovered exploit. It is impossible to account for every situation. Use at your own risk. Never share your private keys or seed phrases, and never say them out loud with Momin’s pet parrot nearby. (Rocco remembers and repeats…)

xCMK Launch Notes

The post will explore how our token, $CMK, will function within the platform. However, we will start by explaining the following: 

Functions users will be able to use after MVP launch.

Why is Credmark crucial in the current state of DeFi?

The rapid rise of DAOs and new protocols will inevitably drive demand for scalable, non-custodial services, such as: liquidity as a service for deep liquidity, insurance, multisig management, treasury management, payroll, and on-chain data.

As DAOs and protocols become more sophisticated, they will also need 

. Proper risk management requires access to high integrity data as well as expert analyses. As a DAO that collects blockchain data ETL and conducts risk research, Credmark is well-positioned to address this demand.

Conventionally, organizations either develop risk management strategies in-house or they delegate this to an external risk service provider.

The in-house option requires hiring, training, and maintaining an in-house risk team, which many organizations are not equipped to do. As a result, such organizations opt for external risk firms.

However, putting data in the hands of an external service provider is fundamentally incompatible with the non-custodial nature of DAOs.

In addition, relying on traditional risk firms is simply not sustainable, since these firms cannot keep up with:

surging demand from an increasingly large number of DAOs

rapidly evolving protocols, business models and forms of governance

This is why we at Credmark believe that a DAO-to-DAO model is the answer.

A DAO-to-DAO model allows different communities to partner up in a non-custodial and permission-less way.

Credmark believes providing DAOs with the right tools and frameworks is key to preserving their decentralized nature. Organizations and individuals can also enjoy an unprecedented level of interoperability without needlessly worrying about time and resources invested like what often happens in centralized environments.

Building towards decentralization requires leveraging the expertise of the platform. Naturally, as the infrastructure is gradually built out, developing new tools and framework to adapt to changing climates is crucial.

For example, when a DAO requires risk assessment into a specific pool of assets, our platform would be able to consolidate the data and bring together relevant modelers to help define the risk parameters. However, risk can also adjust over time. Building the foundational infrastructure for the community to utilize is of the utmost importance.

Such is the nature of an ecosystem — providing a scalable one stop solution.

So that’s where we want to end up. But where are we now?

The Credmark Platform will go live on Dec 15th.

. This allows you to access the risk terminal, and to get rewards and future revenue from the Credmark Platform.

The Credmark DAO will be using our Community Treasury to 

This will start at a very high interest rate that will decline as more people stake their $CMK. 

 are issued upon a user staking or un-staking, so that the value of xCMK is always higher than $CMK, and grows at a minimum frequency of every 8 hours.

. This will show our risk metrics that we develop. We’re starting with live and historical 

 for Aave and Compound, and will be adding more factors and protocols every month.

As the platform matures, the data viewed on the Risk Terminal will be come available via API. This API will be the core product offered by the Credmark platform. Our 

 will acquire and stake $CMK in order to access the API, 

 will acquire and stake $CMK in order to build and submit models and 

 will acquire and stake $CMK in order to guide the development of models.

, we want $CMK holders to stake on our platform to help stabilize the ecosystem while also earning rewards.

With $CMK ‘s upcoming staking features, many are wondering what’s going on with our 

The purpose of $CMK native staking is for stabilizing the platform whereas the crucible program is focused on providing liquidity. Every time we add rewards, it is set to expire in 5 months. The last time it was set was 2 weeks ago so there will be another 4 and a half months left of rewards.

If there is a demand for more liquidity, then consequently more rewards will be added. With native staking of $CMK, the APY will be very high and drop as more participants join in.

Credmark Platform and Tokenomics: Part II

November was month of putting in the work.

Credmark Blog

For the latest technical analysis, partnerships, and community updates