As we move into 2023 after a particularly challenging year marked by several black swan events all throughout the DeFi space, it appears interesting to perform a broad assessment of the current state of the derivative market and analyze each of its key components in order to highlight the dynamics that will most likely impact if not led the development of the market in this coming year. 

Main insights

• The Grayscale premium trade aftermath will most likely continue to have ripple effects onto the industry and potentially cause additional contagion among key industry players (GDC, Gemini, …) if no settlement can be found among the different parties.

• Futures and Perpetuals volumes should start to rise again from their 2022 year-end bottom levels, as the space start to rebuild with more transparency and better fit to market products attracting new institutional investors prioritizing derivatives to gain exposure to BTC and ETH ecosystems.

• Investors will have to remain cautious of the regulatory risk given the increasing scrutiny of international regulators on crypto assets and the regulatory by enforcement strategy employed by the SEC in the US.

• The emergence of new investment vehicles in the derivative market (structured vaults, perpetual options…) could bootstrap the emergence of new interesting opportunities for investors while enabling the inflow of additional liquidity in the market.

Grayscale premium trade

Despite its already dramatic effect on the entire industry over the past year which led the to the bankruptcy of several key industry players (FTX, 3AC, …), the aftermath of the industry wide Grayscale Premium trade still continues to spread contagion and fear throughout the market following the recent collapse of FTX and its ripple effects on Genesis, DCG and Gemini**.**

Furthermore, adding fuel to the fire, the refusal of Grayscale to show public proof of its BTC holdings as well as the growing public tensions between Gemini and Grayscale’s parent company DCG over a $1B liability recently increased the selling pressure on $GBTC shares pushing the Grayscale discount over -40% towards the end of 2022. As such, it appears important for investors to remain cautious of this risk in their investment choice during the first half of 2023 and price in the eventuality of additional headwind across the crypto sector coming from this unresolved situation.

Grayscale premium TLDR

Initially profitable the Grayscale trade consisted for eligible institutional investors to exchange with Grayscale a given amount of BTC for $GBTC shares to then resell those shares on the secondary market at a premium to retail investors who prior to 2019 couldn’t get any real exposure to BTC on traditional financial market outside of $GBTC. However, the situation quickly reversed in 2021 with this premium becoming a discount following the added selling pressure on $GBTC coming from an increasing number of institutional investors entering the trade as well as the growing options at hand for retails investors to get exposure to BTC through BTC future ETFs (CME, …).

Resilience of the derivative market

All throughout this past year, the derivative market showed growing signs of maturity as it continued to gain additional market shares against the spot market while also being able to ensure sufficient liquidity during the several period of high volatility that we encountered.

Indeed, even though the future and perpetuals markets suffered from a steep decline in volume across the year following the collapse of numerous institutional market participants on both the seller and buyer side (3AC, FTX, …), we can see that those markets reveal themselves mature enough to enable investors to hedge their portfolio risks during period of high risks as shows the below peak volume of future trading during the collapse of FTX.

Inability of the option market to reach mainstream adoption

On the contrary of perpetuals and futures which quickly became soon after their release among the most popular and traded assets on both centralized and decentralized derivative marketplaces, option derivatives still remain a pretty nascent and low volume market focusing mostly on BTC and ETH.

Nonetheless, existing use-cases in risk management such as custom options strategies for Liquidity providers enabling to hedge the convexity of the impermanent loss risk or underdeveloped option products such as hash rate options enabling miners to hedge away the hash rate risk on their mining ROI could create new opportunities for this asset class in the short term future. Similarly, new type of options such as everlasting options still complex to price could also become a really interesting tool if able to find a good market fit in the ever-changing DeFi landscape. As such, investors should remain informed on this asset class as its current underdevelopment could hide an important untapped growth potential.

Increasing regulatory risk

Following the recent demise of numerous high profile crypto companies involved in the Grayscale premium trade the hope for more regulatory transparency through the approval of a spot BTC ETF under the actual SEC chair Gary Gensler disappeared altogether. Worst, due to the massive implication of SBF in the draft of the forthcoming crypto bill scheduled to be soon presented in front of the Congress, chances of congressional vote on a “crypto bill” appear now pretty slim and investors will most likely have to wait for the election of a new administration to see the passing of a crypto bill bringing more clarity onto the sector. Consequently, investors will have to remain in the meantime cautious of the regulatory risk coming from the pretty aggressive legislation by enforcement led by the SEC when investing in tokenized derivatives.

On the other hand, for pure derivative products falling under the purview of the CFTC, investors will also need to remain aware of the regulatory risk and of the previous decisions of the commissions which despite being more consistent than the SEC still remain nonetheless willing to assert its authority on this new sector.

Dominance of centralized derivative marketplace

 In line with the situation observed in the spot market, both from a volume and open interest standpoint centralized derivative marketplaces still remain ahead of fully decentralized marketplaces by several orders of magnitude despite the recent scandals which tainted several centralized derivative actors and the increasing trend among crypto native users to rely more and more on self-custody.

However, with the current growing momentum around Ethereum scaling solution enabling low gas fees and the increasing reliance of the DeFi sector on a growing number of AMM pools requiring liquidity hedging, it is to expect that the market share of the decentralized derivative marketplace will likely increase over the course of the upcoming year.

Tether’s monopoly challenged

Building-up on its growing momentum following the different 2021 USDT scandals, USDC continued all throughout 2022 to consolidate its place of best USDT alternative for investors wary of transparent auditing process and even came close to challenge Tether in terms of market cap despite a continued dominance of the latter in terms of daily volume traded. 

Nonetheless, given its highly transparent auditing process and partnership with major players such as VISA or BlackRock, USDC seems on a good path to be able to challenge further Tether’s monopoly throughout the coming year as it already did successfully inside the Ethereum ecosystem. 

Brewing derivative innovation

Despite an interesting pace of innovation in the derivative sector with several new tools designed over the past year and a half (everlasting options, structured vault, floating strike options …) the adoption and infrastructural development around this new market segment was not able to follow-up given the larger focus on the numerous scandals that impacted the market over this past year which induced a liquidity crunch and a flight to safety from investors. Nonetheless, despite this mild set back, those new products seem now really well positioned to be able to finally hit the market and offer interesting new range of investment types all across the DeFi space during the course of 2023.

Disclaimer: All information/documents contained in this blog rely solely  on my personal beliefs, and do not constitute professional investment advice.

Be careful in your investment and do not invest more than you can afford to lose.

Today’s tutorial will be mainly divided into two parts. First we’ll finalised our cloud data architecture and make sure that it updates itself automatically on a daily basis. Then, in a second time we’ll hop onto the creation of our Grafana dashboard and see how we can connect our ethdb database to a Grafana instance in order to create our ETH analytics dashboard.

Part 1: Cloud data architecture finalization

Alright so first thing first, now that we have at our disposal our basic cloud data architecture with each of our tables initialised we need to create python scripts enabling us to update each of those with new daily metrics.

Observation: In the case of the daily_metrics and delayed_metrics tables given that we only extracted the latest daily metric value available we don’t need to recreate additional python scripts and can directly used the python functions that we used in our table_init2 and table_init3 python scripts.

Alright so let’s focus on the case of the historical_metrics and network_growth tables. So here basically the idea, is to create a python script in order to add on a daily basis the new daily metrics value to each tables.

Starting, with our historical_metrics table, let’s create a new updating python scripts called historical_daily.py in our code folder using the following command:

$ nano historical_daily.py

From there copy and paste the code that you can find here in the corresponding file in Github.

Observation: Here the code is basically exactly the same that we used before in our previous tutorial in our table_init.py script at the difference that here we’re only focusing on extracting the metric value for the current day.

Alright from there using the same process let’s take care of our network_growth table. So first we’ll create a new python script using the following command:

$ nano network_growth.py

From there copy and paste the content of the github file of the same name:

Alright, now we have to make those scripts executable and run them. To do so we’ll use the following commands presented in our previous tutorial:

$ chmod +x historical_daily.py 
$ chmod +x network_growth.py 
$ ./historical_daily.py 
$ ./network_growth.py

Here if everything goes well you should be met with our usual prompt message '“Process done'“ after the running of each of our python scripts.

Note: if you want to double check, feel free to use the same process explained in our previous tutorial using the Postgres user and your local instance of psql.

Alright so now that we’re all set and have our full data architecture, let’s automate this daily updating process. To do so, first we’ll need to create a python script that we’ll call main.py which will call all the functions we need to perform a full daily update of all our tables composing our cloud data architecture.

So first let’s create, that new python script in our code folder using the following command:

$ nano main.py

From there as usual copy the content of the corresponding github file in your editor:

As you can see here, this file is pretty straightforward we basically just import each functions that we need from their respective python scripts and run them one after another.

Alright so from there, as always we need to make this script executable using the following command:

$ chmod +x main.py

Once it’s done the last thing we need to do, is to ask our cloud server ro automatically run on a daily basis this script. To do so, we’ll use a linux tool called crontab enabling us to ask the computer to perform a set of task on a periodical basis. So first let’s open crontab using the following command:

$ crontab -e

Choose the easiest editor by typing 1:

Normally you should be met with the following editor:

From there type the following command below the comments, save and exit the editor.

$ 0 9 * * * ./main.py

See here for crontab time converter

And that’s it we finally have a complete full cloud data architecture querying and storing our needed metrics value on a daily basis 👍

Alright so that’s a pretty big part done, so don’t hesitate to make a quick coffee break here if you need it before heading to the second part ☕

Part 2 Grafana dashboard creation

Alright so let’s start building our Grafana dashboard. First, if you haven’t already created one go on the Grafana website and follow the onboarding steps in order to create an account.

Once you’re done you should be able to see the following screen:

So first, let’s create our dashboard. To do so, hoover over the dashboard icon and click on “new dashboard”.

From there click on '“Add new panel” and click on “save” in order to save your new dashboard as shown below:

Alright, so now let’s connect our ethdb database stored in our cloud server to our Grafana instance in order to get access to our ethereum network metrics.

So first let’s click on configuration and go into Data sources.

Once you’re there click on add datasource

From there seach for postgreSQL and select it in order to add a new PostgreSQL data source to your Grafana instance.

Here we have to specify the following connection parameters:

• Name -- the Grafana name we want to give to our data source. Here we’ll call it ethdb

• Host -- which corresponds to the IP address of our DO server and the port that Grafana should use to connect to it here it is “:5432” (as per Digital Ocean default parameters)

• User -- which corresponds to the user that we use to connect to our database located in our cloud server. Here we’ll use our previously created user called “myuser” the password being the password you assigned to your psql user.

• TLS/SSL Mode -- Disable

Once you specified all the parameters presented above, click on “Save & Test” and if everything goes smoothly you should see appear the following message

Alright so now that we connected successfully our ethdb database to our grafana instance let’s start building our Grafana dashboard. So first let’s get back to our dashboard and edit our panel

There click on data source and select ethdb

Once it’s done, in the query section click on the code option in order to be able to start writing SQL queries and use the following command:

select date, historical_prices 
from historical_metrics
order by date asc;

Upon running the query you should end up with the following result:

Don’t forget to select the “last 6 months” time range given that it is not the by default used time range by Grafana.

From there you can customize your graph as you want using the panel options and once you’re done don’t forget to save all your changes.

Alright so now that we’re down with our price chart let’s go ahead and create another panel in order to create our current price counter.

From there as before choose ethdb but this time copy and paste the following sql command in order to extract the current ETH price from our daily_metrics table.

select date, price 
from daily_metrics 
order by date desc
limit 1
;

Normally you should end up with the following result:

Here, switch the visualization from time series to stats and delete the threshold in the panel options before saving it.

Alright so now moving on to our daily volume counter using the same process and the following SQL command we obtain a counter with our daily volume.

select date, volume 
from daily_metrics
order by date desc
limit 1; 

Observation: Our volume here is expressed in billions so if you want to also show that in Grafana you can use a transformation by clicking on transformation and on the “Add field from calculation” button as shown below:

Then in order to only get your value in billion showed in the counter go to the panel options and select your newly added columns in the Fields section.

Alright so for the two other counters we’ll basically use the same process and use the following SQL queries.

Social Volume:

select date, socialvolume
from delayed_metrics
order by date desc
limit 1
;

24h active addresses:

select date, activeaddress 
from daily_metrics
order by date desc
limit 1;

Normally if everything goes right you should end up with a dashboard similar to the one below:

From there, the building steps being mostly the same in order to create the rest of the below dashboard I’ll let you try to do it on your own as an exercise by relying on the below code snippets showing you which sql queries you should use to create each of the neeeded dashboard components.

SQL queries:

Velocity

select date, volatility
from delayed_metrics
order by date desc
limit 1;

Marketcap

select date, historical_marketcap 
from historical_metrics
order by date asc
; 

Top holders

select date, topholders
from delayed_metrics
order by date desc 
limit 1; 

Github activity

select date, githubactivity
from delayed_metrics
order by date desc
limit 1; 

Dev Activity

select date, devactivity 
from delayed_metrics
order by date desc
limit 1;

Network Growth

select * 
from network_growth
order by date asc;

And that’s it !! 🥳🥳

So congrats if you reach the end of this tutorial serie, you’re now well equipped to go further and start tackling further challenges so be proud of yourself and as always don’t hesitate to play around with the code and fine-tune it to your liking 😃

In the future we’ll go further and introduce other DevOps notions such as kubernetes, docker and others tools so stay tuned if you’re interested to learn more about those and in the meantime have fun with all this new knowledge.

Take care 🖖

Oryen Network

Oryen Network a new upcoming staking protocol enabling investors to yield high-passive income through a new auto-compounding tool announced the roll-out of its 7th presale’s phase later on this week.

Ankr

Earlier last week, Ankr reported a successful $5M hack of its aBNBc token contract through an unlimited mint bug and halt trading for several days before resuming operations earlier this week and reimbursing all affected users.

Aave & Compound

DeFi giants Aave and Compound recently decided to cap loans and freeze a number of token markets in order to enhance the overall security of their cryptoeconomic designs and prevent liquidity attacks such as the one attempted earlier this year by Avraham Eisenberg

Web3

Aurox

Aurox a leading DeFi-focused software development company, aiming to compete with Metamask, recently unveiled its new web3 wallet extension enabling users to profit from industry-leading security features as well as from an innovative reward program being applied on each transaction.

Permaswap

Arweave’s first cross-chain DEX Permaswap, recently announced the successful ending of its second testnet phase and officialy announced the upcoming release of its Beta version.

RedStone

Earlier this week, Redstone announced a new partnership with the Fantom network aiming to enable developers to build data-driven decentralised applications on top of the Fantom network in a fast and reliable way.

Ecosystem

Vitalik

In a recent blogpost, Vitalik Buterin, co-founder and chief scientist of Ethereum, weigh-in on the decentralised voting system debate arguing that token value should not be tied to their democratic utility given the risk of attacks by specialised investors and the negligible leverage of retails users in those type of governance framework relaunching as such the heated debate around the best type of possible decentralised governance.

US regulators

The Financial Crimes enforcement Network (FinCEN) recently stated that it is looking carefully at DeFi and referred to digital currencies as its key priority area making some market participants fear a strengthening of the future regulatory framework for DeFi companies in the US.

Market

• BTC     $17,237

• ETH $1285

• BNB. $290

• ADA. $0.31

• SOL $13.89

Perennial

Perennial, a decentralized-finance derivative trading platform recently successfully closed a $12 million seed funding round that led by Polychain Capital and Variant.

Auros Global

Crypto trading firm Auros Global appears to be suffering from FTX contagion after missing a principal repayment on a 2,400 Wrapped Ether (wETH) DeFi loan.

Disclaimer: All information/documents contained in this blog rely solely  on my personal beliefs, and do not constitute professional investment advice.

Be careful in your investment and do not invest more than you can afford to loose.

Validity of Enzyme Finance main use cases [ Score 4/5 ]

Treasury management

• Flexible purpose-built asset management toolkit enabling DAOs and companies to implement custom treasury management architecture

• Possibility to grant limited operational power on specific treasury management process to a small subset of members or to a specialized third party.

• Built-in integration of Gnosis Safe* allowing the creation of a layered treasury management structure implementing different signature thresholds for each treasury management actions.

• Complete treasury management transparency thanks to Enzyme’s user-friendly UI enabling DAO members and token holders to easily monitor treasury state at all time

• Publication of transparent and easily readable reports on assets being managed

• Reduction of admin private key operational risk through the leveraging of Gnosis multi-sig wallet

• Custom policy features allowing the limitation of asset managers rights to a limited number of actions pre-vetted by users through community vote on Snapshot.

Investment Clubs

• Possibility to implement main DeFi services in Fund strategy thanks to Enzyme’s integration with several external DeFi protocol (Aave, Maple Finance, Compound …)

  • Current available services:

    • Yield Farming

    • Synthetic asset & Derivative

    • DEX’s swap

    • AMM pools

    • Borrrowing & Lending

• Unique possibility to create strategies relying on external positions not resulting in a simple exchange of ERC20 assets (Compound cTokens, Uniswap v3 LP positions, …)

• Unique possibility to create strategies relying on external positions not resulting in a simple exchange of ERC20 assets (Compound cTokens, Uniswap v3 LP positions, …)

• Large set of available policy features allowing to create a variety of gated and public investment clubs with varying level of trust towards the asset manager

• Possibility for investors to withdraw liquidity without restriction 24/7

• Easy implementation of trading bot through Enzyme policy feature enabling the community to grant revocable trading rights to a given address

Current Ecosystem State [ Score 3/5 ]

• Development of interesting new features diversifying the type of holdings available for investment strategist (External position, airdrop claims, …)

• Mature and successful decentralized governance architecture

• Limited set of adapters enabling the integration of Enzyme with external DeFi protocol:

  • 16 available adapters on Ethereum

  • Only 8 adapters on polygon

  • 2 upcoming adapters (Notional Finance & Pool together)

• Asset pricing mechanism still heavily reliant on Chainlink price feeds

• Ecosystem still mainly targeting crypto native users given the technological understanding required to use the platform (Web3 wallet private keys management, handling of different networks, …)

• Investors token ownership preventing most institutional investors to take part in that ecosystem due to regulatory limitations

• Limited set of supported networks (only Ethereum & Polygon)

MOAT (Long-Term stability of use case and ecosystem) [Score: 3/5 ]

• Recent move of crypto native users towards more decentralized investment platforms following the recent FTX meltdown which will most likely attract new users towards Enzyme asset management solution.

• Continued growth of the DeFi space and of DAOs in a broad array of sectors ranging from gaming to social media (Lil Miquela, …) structurally supporting the demand for decentralized asset management solutions such as Enzyme

• Huge future opportunities in the investment sector with hedge funds and investment banks most likely to start leveraging platforms like Enzyme once the regulatory framework around token ownership will have been clarified by regulators worldwide.

• Strong insurance regarding the continuing development of the core Enzyme protocol thanks to the recent renewal of Avantgarde Finance contractor agreement as lead protocol developer up until September 2025.

• Additionally with the recent growth of investment clubs, Enzyme could also become an ideal decentralized investment solution for retail traders communities such as WallStreetBets willing to invest on crypto

Project maturity / Age token (years since existence) [ Score: 4/5 ]

• July 2016 — Creation of Melonport AG as a privately domiciled company in Zug, Switzerland with the sole mandate of developing an asset management computer built on top of Ethereum.

• February 2017 — ICO raising $2.9M in one day

• February 2019 — Launch of Mainnet v1.0

• August 2019 — Ownership of the protocol transferred to the Melon Council DAO

• December 2020 — Rebranding from Melon Protocol to Enzyme

• January 2021 — Launch of Mainnet v2.0 (after failure of v1.0) implementing a brand new smart contract architecture as well as a full suite of new features developed in partnership with the community (lending, synthetic assets, yield farming, …)

• February 2022 — Launch of Mainnet v4.0 (Sulu)  building on top of the success of mainnet v2.0 and implementing a whole suite of new features and integrations.

• Unknown — Release of Mainnet v5.0 (Eve) aiming to iterate on the success of Sulu and expand further the range of applications and potential use cases of Enzyme

Analyst Observation

• High level of community governance enabling to pivot quickly and align at best with the need of users as shown by the quick pivot from mainnet v1.0 to mainnet v2.0

• Continuous development led by a team of seasoned developers with deep understanding of the space and true beliefs in the long-term mission of Enzyme as shows the grant token vesting enforced in the recent contactor agreement renewal

• Currently among the top three decentralized asset management solutions in terms of TVL.

Revenue Potential

Last 12M Revenue [ Score 3 /5 ]

AAGR = - 83%

Analyst comment

By comparison with the annual growth returns exhibited by other major crypto assets such as Bitcoin (-72%) and Ethereum (-73%) the current AAGR of Enzyme does not seem worrying especially in the current context of severe contraction of the crypto space due to the consecutive occurrence of black swan events all throughout the year (Terra, Three Arrows Capital, FTX, …).

Revenue Trend (Last 3 months vs Last 12 months) [ Score 3/5 ]

3 month Growth rate = - 23%

Analyst comment:

The comparison here between those two revenue trends does not really help us getting a clear picture on the intrinsic protocol revenue generating power given the occurrence of consecutive black swan events during both of those time periods.

Revenue flow to token holder [ Score 2/5 ]

Cryptoeconomic design

• Current token circulating supply: 2,038,518 MLN

• Maximum mintable tokens per year: 300,600 MLN

• Built-in burning mechanism of protocol fee

• Governance burning of any unused residual amount of MLN minted for development purposes

Value accrual mechanism

The burning of all protocol fees applies a deflationary pressure on the overall circulation supply of MLN tokens which in return enable token holders to benefit from the token price appreciation.

→ The goal being that the protocol becomes deflationary in the long run given enough usage.

Current state

• Overall MLN tokens burned since launch = 382,522 MLN

• MLN Circulating supply = 2,038,518 MLN

• MLN tokens burned / MLN circulating supply = 18.7%

Observation

This means that in three years the Enzyme council has effectively burned 18.7% of the circulating supply of MLN tokens.

Valuation [ Score 3/5 ]

Given that all protocol fees get burned by the protocol it appears more interesting here to compare the market cap with the TVL instead of with the amount of protocol fees.

Current market cap/TVL ratio = 1.11

As demonstrated by the current market cap to TVL ratio, the protocol seems a bit overvalued at present. As such, it would appear better for investors to wait additional token price corrections before investing in the project.

Comparison with competitors in terms of TVL (source DefiLlama)

Global in/out of the money

As shows the above graph from IntoTheBlock, most of MLN token holders are currently out of the money suggesting a high selling pressure on the token and strong levels of resistance ahead, especially in the range $20 - $50.

Number of Large Transactions

Daily number of on-chain transactions greater than $100,000

Not a lot of activities currently on the protocol outside of small retail investors.

Average Balance growth ($)

Average Balance growth = - 81%

AAGR = - 81%

Interesting to note that users didn’t massively exit the protocol over the past year and globally stayed invested in the protocol in the same relative proportion.

Twitter sentiment

Mixed user sentiment over the past week but overall good twitter sentiment over the past year.

Team

Governance architecture [ Score 4/5 ]

The overall Enzyme protocol governance is ensured by the Enzyme Council DAO itself divided into two sub DAOs :

• The Enzyme Technical Council (ETC) — Providing technical expertise and in charge of making decisions on core technical topics such as protocol upgrades, resource allocation or network parameters.

• The Enzyme Users Representatives (EUR) — Collecting, prioritizing and delivering users feedback to the Enzyme Council on behalf of users.

Current Enzyme Council members

• Chain Security (ETC)

• Exa: Co-founder of Exponent (ETC)

• Janos Berghorn: Investor @KR1 (ETC)

• Giel Detienne: User representative (EUR)

• Mona El Isa: Founder & CEO @Avantgarde Finance (ETC)

• Felix Hartmann: Founder @Hartmann Capital & User (EUR)

• Will Harborne: Founder & CEO @Deversifi (ETC)

• Nick Munoz-McDonald: Smart Contract Auditor & Researcher @G0 Group (ETC)

• Paul Salisbury: Founder @Blockchain Labs (ETC)

• Zahreddine Touag: Founder @Woorton (ETC)

• Theophile Villard: Co-founder of Multis wallet, contributor to Enzyme codebase (ETC)

Tech leadership and ability to fill gaps [ Score 4/5 ]

As per the recent approval by the Enzime Council of the new protocol development grant defended by Avantgarde finance, this latter will continue to be up until September 2025 the lead developer of the core Enzyme protocol as well as of its growing ecosystem.

Additionally, as per this new grant, Avantgarde finance will also support and develop in partnership with Enzyme a new marketing strategy on par with similar effort across the space in order to attract new users to the platform.

Past achievements of Avantgarde Finance as lead protocol developer:

• Three major releases in the space of 28 months.

• Integrations with some of the biggest and most widely used protocols in DeFi

• Development of a sophisticated set of subgraphs tracking important metrics

• Complete UX/UI development

• Management of numerous bug bounty programs

Overall the Enzyme protocol benefits from a high level and dedicated core dev team with an impressive past track record which will most likely have no difficulty to further continue the development of its core features in order to ensure its long term success.

General team business dev and marketing capabilities [ Score 3/5 ]

Generally speaking, the Enzyme Council is in charge of the marketing efforts alongside Avantgarde finance through the distribution of grants allocated through vote proposals.

Example

$35,000 grant approval for Messari coverage of Enzyme through a dedicated webinar as well as a serie of dedicated reports published on Messari’s website and distributed through its newsletter.

Backers and funding strength [ Score 2/5 ]

Enzyme finance exhibits two main sources of funding:

• ICO held in 2017:

  • Start Date: Feb 15, 2017

  • End Date: Feb 16, 2017

  • Total raised: $2.9M

  • Country: Switzerland

• Yearly protocol minting allocation of 300,600 MLN for ensuring protocol development

Given that the main current source of funding of the protocol is by design denominated in MLN, it is critical for the project that the MLN price doesn’t fall too low at the risk of hindering any future development and even create a sort of a death spiral if breaking a certain floor price (not enough funds to pursue development  further decrease of the price  even less found to upgrade the protocol …)

Security

Token governance [ Score 3/5 ]

As highlighted before, the token governance is ensured by the Enzyme Technical Council.

Main token governance topics:

• Resource allocation: The yearly inflation of MLN being the sole resource available to fund the development of the Enzyme protocol, prioritizing and executing its allocation in a mindful manner is of the utmost importance.

• Network parameters: Asset management gas price per amgu as well as protocol fees needs to be set according to network usage and market conditions in order to ensure the optimal performance of the Enzyme protocol.

Token holder concentration [ Score 3/5 ]

Top 10 holders distribution

Top holders incentives: Given the perspective of the protocol becoming deflationary in the mid/long term, top holders are incentivized to hold their tokens in order to then be able to profit from a passive source of profit due to the mechanical price increase of the MLN token.

Sources

Protocol documentation and additional information sources

• https://docs.enzyme.finance/

• https://specs.enzyme.finance/

• https://enzyme.finance/

• https://github.com/orgs/enzymefinance/repositories?type=all

• https://medium.com/@avantgardefi

• https://medium.com/enzymefinance

• https://medium.com/@meloncouncil

• https://messari.io/asset/enzyme-finance

• https://app.enzyme.finance/discover/assets

• https://www.youtube.com/@enzyme9189

• https://snapshot.org/#/enzymefinance.eth

• https://twitter.com/enzymefinance

• https://discord.enzyme.finance/

Data sources

• https://etherscan.io/token/0xec67005c4e498ec7f55e092bd1d35cbc47c91892?a=0xd8f8a53945bcfbbc19da162aa405e662ef71c40d

• https://coinmarketcap.com/fr/currencies/enzyme/

Disclaimer: All information/documents contained in this blog rely solely  on my personal beliefs, and do not constitute professional investment advice.

Be careful in your investment and do not invest more than you can afford to loose.

Alright so today the roadmap will be a bit longer than usual so hang tight and don’t hesitate to make breaks between the different parties if necessary 😉

Tutorial roadmap:

• Creating a new PostgreSQL user and our database

• Creating our tables using python scripts

• Performing the initial data input of our tables with python

Part 1: Creation of our Postgresql database

Alright so first thing first we need to create a new PostgreSQL database in which we will develop our data architecture with our different tables. So let’s do just that by ssh into our existing DO droplet.

From there given the default installation of PostgreSQL in Ubuntu we have to switch from the root user to the postgres user, using the following command in order to be able to access our PostgreSQL instance.

Alright so now let’s create our dedicated postgres user that we’ll use to access remotely our database. To do so use the following command and fill up the prompt as shown below:

Note: Ideally it would be best to avoid creating our new user as a superuser given that we’ll use it later to connect our database to Grafana. However given that it is just an introductory tutorial here we’ll consider that it is good enough from a security standpoint given the non-existent security risks.

To check that your new user has indeed been created you can use the Postgres Shell as follows:

Type psql in your terminal to access the Postgres shell as shown below

From there, type the following command:

$ \du

From there you should be meet with a table of the following format inside of which you’ll see your new user.

Alright so from there exit the postgres shell, using the following command

$ \q

Then still using the postgres user type the following command in order to create a new database called “ethdb” that we’ll assign to our newly created user.

$ createdb -O myuser ethdb

Alright and that’s it for our first part we now have our database and a dedicated user to access it, so make a quick break if needed before jumping to part 2.

Part 2: Creation and initialisation of our metrics tables using python scripts.

Alright so now let’s create the tables that we’ll use to store the network metrics that we want.

⚠️ ⚠️ Don’t forget to come back to the root user before continuing by using the following command:

Alright so from there use the following command to list all the available folders at the current level where we at:

$ ls

Normally you should see, the following:

So from there use the following command in order to get one level higher up in the folder architecture of the server:

$ cd ..

There if you use the previous “ls” command you should get the following result:

Alright so now that we’re at the right level let’s start by first creating the folder in which we’ll store our python script. To do so, use the following mkdir (make directory) command:

$ mkdir tutorials
$ mkdir tutorials/introduction 
$ mkdir tutorials/introduction/code 

Now let’s enter our introduction folder:

$ cd tutorials/introduction

From there let’s create two additional text documents :

• A ReadMe.txt file in which we’ll present an overview of our project

• A Requirements.txt listing all the packages and version requirements to run this project

To create those two files we’ll use here the “touch” command as follow:

$ touch ReadMe.txt 
$ touch Requirements.txt

Normally after all that you should end up with an “introduction” folder looking like the below snippet

Alright so now that we’re all set from a project architecture standpoint, let’s start creating our PostgreSQL tables.

Here given the limitation of the Santiment API provider enumerated in our first tutorial it appears better to create the four following tables:

• historical_metrics: Storing all historical prices and marketcap up to today

• network growth: Storing all historical network growth values up to last month

• daily_metrics: Storing daily value for the metrics where we only want to show in our dashboard the latest current value

• delayed_metrics: Same as daily metrics table but for metrics where we only have access to past month values

In order to create this data architecture, let’s get back to our terminal and enter into our code folder.

Note: Depending on where you are inside your folder architecture the command might changed so keep in mind that to enter inside a folder at a particular level you only need to use the following command:

$ cd [name of the folder you want to enter]

and if you want to go back of one level just used the following command:

$ cd ..

Alright so once you’re into the code folder, go ahead and create a new python file by using the following the following command:

$ nano init.py

From there you’ll end up in the nano text editor which is with Vim one of the most common text editor used in Linux.

From there go to the github page of the tutorial and copy and paste the content of the init.py file inside the nano shell.

Let’s unpacked a little bit the code that we used here.

So first we import the psychopg2 python package that will enable us to connect to our Postgres instance through Python.

Then we define the create_tables() function composed of two blocks through which we’ll create each of our tables.

• Block 1: We create a command variable composed of usual SQL commands in order to create each of our tables with their respective metrics.

• Block 2: We use a try - except block in order to try to connect to our local PostgreSQL instance and create a cursor that we’ll then use to execute the content of our command variable.

Finally, we run our function in order to create our data architecture in our PostgreSQL database.

Alright so now that we now what the code is doing let’s run it in our distant server. To do so first save all modifications made in the nano text editor by pressing ctrl + s and then exit by pressing ctrl + x.

Once back into the code folder install the psychopg2 package with the following command:

$ pip install psychopg2

Then from there we have to make our script executable. To do so we’ll use the following command:

$ chmod + x init.py

Normally if everything went well you should see the name of your init.py file appearing in green. From there, just type the following command to run your python script in your remote server:

$ ./init.py 

Alright so here normally if everything worked you should not receive any message once the script has finished running. However, it’s always better to double check so reusing the same method used before we can easily check if we indeed created those tables using the following sequence of commands:

$ su - postgres 
$ psql 
#We enter here into the Postgres shell 
postgres=# \c ethdb 
ethdb=# \dt

Note:

• The “\c ethdb” command is a psql command allowing to connect to the ethdb database

• The “\dt” command is a psql shortcut enabling to list all available tables

• Here the “user1” mentioned comes from the fact that I used another user name tag when creating this tables

Alright so now that we have our table let’s go ahead and populate them.

Part 3: Initial data populating of our psql tables

As before for the creation of our psql tables, we’re also going to use python scripts. However, this time we’re going to have to make API calls to Santiment API through reusing the functions that we previously created in our first tutorial.

As such before creating our init.py script let’s create before a new python script called functions.py using the following command inside the code folder:

$ nano functions.py 

And there just copy and paste the content of the function file that you can find here on the tutorial Github repo.

Also don’t forget to make it executable by using as before the following command:

$ chmod +x functions.py

Alright so now let’s move onto our data populating script per se

Script 1 : historical_metric init

Let’s start with our historical_metrics table. First we create a dedicate python script that we’ll call table_init.py:

$ nano table_init.py 

As before, copy and paste here in nano the content of the table_init file available on Github.

Let’s unpack a little bit our code here given that a lot is going on at the same time 😅

So first as you can see in the code we import the functions that we need from our functions.py file, as well as the psychopg2 package allowing us to connect to our local psql instance and other python package enabling us to get access to date variables.

Second we create the update_db() function enabling us to populate our historical_metrics table for each date.

Third we create the populate_table() function which calls our “get_historical_price” and '“get_historical_marketcap” to get all the data point for the past 6 months and use our previous update_db() function on each of those data point to populate our psql table.

Note: As you can see below we also need to a bit of formating on our data given that the data delivered by Santiment API in python is not compatible with our integer psql type.

Alright so now let’s run this python script. So as per usual make it executable and run it with the following sequence of commands:

$ chmod +x table_init.py
$ ./table_init.py

If everything goes smoothly at the end of the process we’ll be met with the following prompt message:

If you want to double check the code execution, run the following sequence of commands:

$ su - postgres
$ psql 
postgres=# \c ethdb
ethdb=# select * from historical_metrics; 

Note: To exit that view press q

Script 2 : network_growth init

Alright so here using the same process, previously employed in the case of table_init.py we create a new python_script to populate our network_growth table called table_init1.py and copy and paste the table_init1.py file from Github:

$ nano table_init1.py 

The code employed here is pretty much the same as the one used before in the case of table_init slightly modified to get the network growth value and take into account the fact that we can only get thet data as far as last month.

From there as per usual we make that file executable and run it.

Script 3: daily_metrics init

Alright so from there we’ll go a bit quicker in our explanation given that we’ll again use the same process.

So create here a file called table_init2.py, copy and paste the content from the corresponding Github file into nano and from there make the script executable and run it.

Script 4: delayed_metrics init

Create a file called table_init3.py, copy and paste the content from the corresponding Github file into nano, make the script executable and run it.

And that’s it!! 🥳🥳

We finally have a full data architecture into our DO server, with a database and a set of tables storing the value of our different metrics so congrats if you came as far as this, it was definitley not easy so give yourself a well deserved pat on the back 😃

Next time we’ll build onto our work to see how to create scripts that populate automatically our tables on a daily basis and also how to connect our psql database to grafana in order to create our ethereum dashboard, so stay tuned for the next and final part of this tutorial serie and in the meantime happy coding!

See you next time 🖖

Link to tutorial Github repo:

https://github.com/Cybergen300/DevOps-Intro

BlockFi

Blockfi officially filed for bankruptcy on Monday, following the collapse of FTX, its main financial backer, which earlier this year rescue the company with a revolving $250 million line of credit that later on morphed into a $400 million credit facility.

Kiln

Kiln a Paris-based startup enabling retail customers to easily partake into Ethereum PoS mechanism through its newly launched staking-as-a-service product recently raised $17.6M in a series A funding round led by Consensys, GSR and Kraken’s venture-capital arm in order to continue the development of its current platform.

WBTC

Following the spreading of a rumour claiming that Alameda Research was among the top wrapped Bitcoin merchants and custodiers, WBTC slightly depegged prompting Bitgo CEO to officially debunk the news on Twitter by exhibiting available on-chain data. Still, at the time of writing the peg still hasn’t been fully restored.

Web3

Bizi

BIZI LABS, the Swiss based mobile platform allowing people to easily access Web3, recently announced that it will integrate the Polygon network into its flagship Web3 partner smartphone brand, ZMBIZI making it the first smartphone combining built-in Web3 features, user rewards, and multi chain functionality.

Consensys

Consensys is currently facing community backlash following the use of a misleading wording concerning users data collection in its recent update of Metamask’s privacy policy which led users to start doubting the claim of fair data usage defended by Consensys and Infura regarding data collection in Infura supported applications.

Carv

Carv a Los-Angeles based start up developing a brand new decentralised identity solution for gaming applications enabling users to move freely between applications and games recently announced the closing of a $4M seed funding round led by Singaporean-based venture capital firm Veterex.

Ecosystem

US regulators

According to a recent report from Barron, several US state regulators are looking into whether crypto trading firm Genesis Global Capital may have violated securities laws with a specific focus on unregistered selling of crypto securities investment.

Japanese regulators

The Financial Services agency (FSA) more commonly known as the top japanese financial regulator recently issued a call for DeFi players to take part in a new “fact-finding survey” on the sector signalling for many a willingness of japanese authority to start regulating the sector some time next year.

Market

• BTC     $16,230.82

• ETH $1,171.9

• BNB $292,95

• ADA $0,30

• SOL. $13,42

Onomy

Despite the current turbulent market conditions, Onomy a Cosmos blockchain based ecosystem aiming to merge decentralised finance and the foreign exchange market to bring the latter on-chain recently an additional $10M funding from Bitfinex and AVa Labs.

Ardana

Ardana, a once-promising decentralized finance project built on top of Cardano, has halted development citing funding and project timeline uncertainty as the main reason for the closing of the project.

Today’s roadmap we’ll be the following:

• Creation of our Digital Ocean Cloud server

• Installation of PostgreSQL on our cloud server

Part 1. Creation of a Digital Ocean (DO) cloud server.

Alright, so first let’s get set up with Digital Ocean. If you don’t have a pre-existing DO account, go here to set it up. You’ll need to input your credit card info but usually there are available promo deals offering up to $200 worth of credit for new users for the first few months. Additionally, given the really small workload that we’ll use even without any promo plan, it wil not cost us more than $5 to perform this tutorial.

Cool, so right after onboarding you should be met with this initial screen, presenting the current state of our project.

So first, let’s customise it a little bit by clicking on settings and modifying our project detail as follows:

Alright, so now that we cleaned up a bit our project let’s move on to create our cloud server also called droplet inside the Digital Ocean ecosystem by simply clicking on the droplet tab inside the manage section.

From there click on create droplet and wait to get redirected to the droplet creation page.

Alright so here as you can see through scrolling the page we have a lot of option. However given the pretty basic project that we’re aiming to realise there is no need here to select ultra fancy parameters. As such we;’ll use the following parameters:

• Distribution: Ubuntu 22.10 x64

• Plan: Basic Plan (Shared CPU)

• CPU options: Regular with SSD ($6/mo)

• Datacenter Region: Choose the one closer to your location

• Authentication: Password

• No additional options

• How many Droplets: 1

• Choose a hostname : DevOps-Intro (or any name of your liking)

Once everything is set click on create droplet and wait for it to be created by the platform.

Part 2. Installation of PostgreSQL in DO server

Great, so now that we have an up and running cloud server, let’s access it in order to install PostgreSQL on it. To do so, let’s open a terminal window on our computer.

➡️ If you’re on Mac go in the finder, browse to application and then click on the Utilities folder and there double click on the Terminal application. If you’re on window, just open the start menu and type cmd before pressing enter.

From there we’re going to ssh into our server. To do so just copy and paste the IP of your droplet shown here:

And type the following command into your terminal:

ssh root@(YOUR DROPLET IP)

If you’re prompted with a message relative to the authenticity of the host in your terminal type yes and press enter. Right after it you’ll get ask your droplet password so again just type it into your terminal an press enter.

From there if everything goes well, you should be greeting by the following welcoming message from your Ubuntu cloud server.

Alright so now that we’re inside our server let’s install PostgreSQL. To do so just copy and paste the following set of command in your terminal:

Command 1: Create the file repository configuration:

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

Command 2: Import the repository signing key

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

Command 3: Update the package lists

sudo apt-get update

Command 4: Install the PostgreSQL 12 version in order to not have any issue when integrating later with Grafana

apt-get install postgresql-12

Note: During the running of this last command you might be asked by the terminal to confirm your command in that case just type Y and press enter.

Alright and now let’s just make sure that everything is operational by checking our installed psql version.

psql -V

And that’s it! You succesfully created and set up your first very own cloud server using Digital Ocean 🥳🥳

So give yourself a pat on the back and don’t hesitate to play around with this new server in order to familiarise yourself with the terminal since next time, we’ll use it intensively in order to create our database architecture.

⚠️ ⚠️

Also don’t forget to exit your remote DO server by typing the following command in the terminal

exit

See you next time 🖖

Uniswap

In the wake of the recent FTX meltdown, Uniswap recently surpassed Coinbase and became the world’s second largest Ethereum trading venue with over $1 billion in ETH daily trading volume.

Solana

The recent downfall of prominent Solana backer Sam Bankman Fried continues to ripple-down on the Solana ecosystem as shows the drop by more than 50% of the SOL price and overall liquidity drop in Solana’s ecosystem over the past two weeks.

DeFi Lenders

While Maple Finance narrowly escaped disaster after closing all loans to Alameda in September, fear of contagion in the sector following the demise of FTX and Alameda Research still remain present in the market. Indeed, despite the already known $12.4M liabilities owed to a variety of corporate lenders (Apollo Capital, Clearpool, …), many market participants fear the potential unveiling of additional hidden liabilities in the coming weeks.

Web3

Sarcophagus

Sarcophagus the famous dead man’s switch dApp developped on top of the Arweave network, recently reiterated its December mainnet release date while unveiling a new live demo of it’s faster and more user friendly V2 version leveraging the Bundlr Network.

Kwil

Kwil, best known for its decentralised SQL development on Web3 recently announced a new partnership with BlockVision in order to help it decentralised its structured data storage architecture.

Trust Wallet

Trust Wallet, a major self-custodial and multi-chain wallet provider recently announced the launch on Chrome, Brave and Opera of its brand new browser extension wallet supporting Solana and all EVM chains.

Ecosytem

DeFi regulation

Earlier this week, in an attempt to fill-up the void left by Sam Bankman Fried, Binance’s CEO Changpeng Zhao, took the stage at Blockbali to voice his stance on the nedeed sector regulation and indirectly propose a new industry partner to US regulators.

Market

• BTC     $16,833.56

• ETH     $1253,67

• BNB     $275.36

• ADA     $0.33

• SOL     $14.30

Sino Global

Sino Global, a blockchain and digital assets-focused investment firm, closely tied to SBF and directly owned by Alameda Research recently announced that despite having suffered mid-seven figures losses the company will nonetheless be able to continue its operations.

Ikigai

As confirmed by its founder, california-based hedge fund Ikigai Asset Management had a large majority of its assets on defunct crypto exchange FTX and will consequently most likely be forced to scale-down or stop all operations.

Dash 2 Trade advantages

• Trading signals providing users with early buy & sell market opportunities

• Social sentiment and on-chain analysis features helping users to spot trending coins

• Custom building tools helping users to create or adopt new trading strategies

• Bespoke scoring system for available and upcoming crypto presales

• Listing alerts on new listing announcements

• Incentivised intelligence sharing mechanisms among users

Project Architecture

From a design standpoint, Dash 2 Trade presents itself as a three-tiered trading subscription platform:

Free Tier — Full access to data terminal and general community channels but limited access to protocol metrics

Starter Tier — Full access to basic protocol tools & features as well as to members only Discord channels.

Premium — Full access to premium protocol features and possibility to take part into incentivised quarterly trading competition.

Interesting to note here, that instead of creating a novel monetization design leveraging staking and other cryptoeconomic features, Dash 2 trade is simply reusing a token denominated version of the usual pricing scheme used by Web2 tech companies (AWS, Google, …). As such, in the current state of things active users may very well, in the future, suffer from price variations on their monthly subscription due to the D2T price volatility.

Observation: A design denominating price membership in FIAT currency and enforcing the payment of said membership fee in the D2T token thanks to the leveraging of an Oracle solution such as Chainlink would have maybe appear better suited from a design standpoint in order to avoid price membership volatility from one month to another.

Project Features

Unique social indicators

Social signals are among the most important valuation factors in the crypto space as most investments in the space tends to be driven first by market perception. Consequently, the Dash 2 Trade platforms offers several social metrics trackings various aspects of market sentiment such as:

• Token/Project related activity on social media (Reddit, Twitter, …)

• Overall sentiment on a network through the leveraging of NLP algorithms

• Dev activity (Github commit, …)

Bespoke scoring system for presales and ICOs

Commonly viewed as a community-powered seed funding phase, presales often provide interesting entry point opportunities on valuable projects. As such, through its dashboard, Dash 2 trade provides dedicated overviews on available tokens presales including report analysis and a custom Dash score assessing the general quality of the project.

Strategy Builder and backtester tools

Developping trading strategies usually require extensive CAPEX allocation due to the need for live experimentation on top of the basic historical simulation operated on past data points. As such, Dash 2 Trades developped a suite of strategy building tools relying on Dash 2 Trade metrics as well as a complete backtesting platform mirroring live market conditions in order to help users to easily and cheaply developed and assess the efficiency of new trading strategies.

Trading tips

Thanks to the myriad of metrics Dash 2 Trade is able to collect from its users activity, the platform internal algorithm can analyse each member trade and compare it to other similar strategies with a better ROI in order to deliver personalised advice on future trades and strategies.

Listing Alerts

New exchange listing announcements can result in significant price changes for a token. As such, for D2T subscribers, immediate access is provided to new crypto listings that the Dash 2 Trade platform identifies, offering as such an opportunity for each and every D2T holders to capitalise on any upcoming listing.

On-chain analytics

Dash 2 Trade is also servicing on-chain statistics for token and wallet activities allowing D2T holders to easily monitor whale movements and market maker dynamics throughout different blockchains.

Social trading

In the future, Dash 2 Trade will also be hosting a number of social trading features and trading competitions for its premium tier subscribers in order to incentivised intelligence sharing across the community and consequently improved the overall level of used strategies among premium-tier members.

Governance

N/A (Currently under development as per the project roadmap)

Cryptoeconomics

Token utility

The Dash 2 Trade analytics dashboard operates on top of the Ethereum blockchain and uses as its native digital asset the D2T ERC-20 token. For now the number of utility ensured by this native token appear a bit scarce given that the D2T token is solely used as payment of the Dash 2 Trade subscription fee. However, given that the governance design is still under development it is important to not draw any early conclusion for now as to the core necessity of the token in the overall project given that following the unveil of the governance model we could see appear staking mechanism ensuring governance rights inside the protocol ecosystem.

Furthermore, it’s also important to note that no transactions tax is enforced by the protocol due to the core team belief that value should ultimately originate from the project and not from people’s transactions.

Observation: Important to flag that currently the available documentation does not really explained where the subscription fees paid by users ultimately end up and how those tokens ultimately get reused by the protocol (burning, selling on secondary market, …). This latter point being a bit worrying for potential investors given that depending on the team’s choice, this cryptoeconomic flow could create a built-in upward or downward pressure on the D2T price.

Token allocation

Ecosystem

Dash 2 Trade team

Duco Van Rossem, CPO

Extensive prior experience in quantitative market research at JP Morgan as well as in other various sectors such as machine learning and Big Data.

André Ferreira, Development Lead

Prior experience in a broad range of tech related roles (Product owner, UX consultant, …) with as strong background in social media and digital marketing.

Orlando Gutierrez, Head Trader

Head Trader of the Learn 2 Trade platform with a strong trading background on broad range of financial markets.

Jarmo van de Seijp, Web3 Engineer

Strong background in Web development and Cybersecurity and prior experience in a variety of Web3 ventures.

Current Partners

Note: Important to highlight that Bullbear.cc is another data analytics venture co-founded by Duco Van Rossem the actual CPO of Dash 2 Trade.

Current state of the presale

Roadmap

Q4 2022, VC Investment

• Create founding team and governance (still in progress)

• Development kick-off

• Trader partnerships

• Presale launch of D2T token

• Full Security Audit

Q1 2023, Website Launch and Presale

• Dashboard Launch and Beta Testing

• Start of subscriptions giving users access to protocol features (Social metrics, technical indicators, watchlist, listing alerts, …)

• CEX and DEX listing for D2T token

Q4 2023, Backtester

• Backtester

• Risk profiler

• Trading competition launch

• Trader AMA’s

• More CEX partnerships, integration of D2T platform

Q2 2024, Auto-trader

• Auto-trader launch

• Trading competition launch

• Integration with CEX API’s

• Competition launch

• Trader AMA’s

• Dash 2 Trade Terminal

• Tradelab

• Mobile App

• Widgets

Q4 2024 Social & Copy trading functionality

• Charting tools

• D2T Social trading features

• Community feedback features

• Further CEX listings

Conclusion

Overall, as a crypto analytics trading platform, Dash 2 Trade appears like an interesting new proposition, servicing a solid one stop solution for investors willing to be able to profit easily from on-chain analytics and key network metrics without having to build their own custom data infrastructure. Furthermore, from a price standpoint with a current monthly tier fee premium around $50, the platform appears like a lucrative future alternative for retail investors hosting their own data dashboard and currently using blockchain API provider with monthly subscription ranging north of $150.

However from a core design stantdpoint, Dash 2 trade still appears to raise a bit too many flags at this stage to be considered as a finalised project. Indeed, from its unclear cryptoeconomic design failing to exhibit a true utility for the D2T token to its lack of membership price stability creating inequality among users depending on the timing of their buying of D2T tokens, Dash 2 Trade appears to need a bit more time to fully adjust its core design.

Nonetheless, before being too categorical it appears important to wait for the release of the protocol dashboard in Q1 next year and monitor the ongoing technical development related to the upcoming release of the governance design to see if the core team will tackle the several issues highlighted above and grant its D2T token additional utility functions instead of solely using it as technical prop giving a web3 feel to an overall interesting new crypto analytic platform.

Disclaimer: All information/documents contained in this blog rely solely  on my personal beliefs, and do not constitute professional investment advice.

Be careful in your investment and do not invest more than you can afford to loose.

Today we’re going to tackle the first part of our introductory DevOps tutorial that will be splitted in 4 distinct parts and through which we will learn among other things how to:

• Handle API calls through Python using Santiment API

• How to properly set up a coding project

• How to create and set up a distant cloud server on Digital Ocean

• Create and manage PostgreSQL database on a distant server

• Build-up data tunnel between an API provider and a distant data server

• How to connect a Grafana instance to a cloud hosted database

Phew! 😬

So as you can see we have quite an awful lot to do here. However, it will all be worth it as by the end of this tutorial we will have a basic understanding on how to create a complete data architecture from scratch, so grab a cup of coffee and once you’re ready join me in the first part of this tutorial.

Project Presentation

So first before diving right-in into the technical aspect of this tuto let’s discuss a little bit about what we’re trying to do here 🤔

Basically, the idea of this tutorial is to give us a “grand tour” of the main DevOps components and skills that are needed to create a full data infrastructure from scratch. As such, I thought that a good way to do just that would be to create the whole back-end data architecture supporting a Granafana analytical dashboard focusing on the Ethereum network and using the following metrics:

• HIstorical price

• Volume

• Token circulation

• 24h active addresses

• Velocity

• Market capitalisation

• Top 10 holders holdings

• Github activity

• Social Volume

• Dev activity

• Network Growth

Alright, so now that we have an idea of what we want to do, the next question is how to do it?

Basically, here we’ll use the most simplistic approach in order to just give you a basic sense of how it can be done. As such, we’ll basically use the Santiment API provider in order to get our needed metrics and then store those value in a set of PostgreSQL databases that we’ll host on a Digital Ocean cloud server. Then, we’ll just connect those databases to a Grafana instance and simply build our Grafana dashboard from there.

Data architecture flow

• Step 1 — Our Python scripts stored in our Digital Ocean server make API requests to extract the needed metrics for our dashboard.

• Step 2 — Santiment API return the metrics value that we reformat and store in our custom PostgreSQL databases hosted on Digital Ocean.

• Step 3 — Our Grafana instance connected to those PostgreSQL tables upload the new metrics values and update accordingly our Ethereum analytical dashboard.

Step 1 Requesting data from Santiment API

Alright so first thing first before thinking about the rest of our architecture we need to create some code scripts in order to extract our needed metrics from the Santiment API provider.

Here we basically have two main possibilities to make our API requests either using curl command inside bash scripts or use the python library developed by Santiment. So even though we could dive right into bash scripting, given that the idea of this tutorial is to keep things simple we’ll instead use the handy python library at our disposal here.

(For those interested, I’ll also do a bonus part of this tutorial where we’ll create the same architecture but using Bash so stay tuned if you’re interested in that 😉)

So first thing first, you’ll need a python IDE, you’re free to use the one you prefer but on my end I’ll use the Spyder IDE coming with the Anaconda distribution so if you don’t have any IDE or want to have the same screen as me just download anaconda from here.

Alright so now that we’re set up, before being able to start coding our python API requests, we’ll need to install the python library developed by Santiment API. So to do that open your terminal and if you’re not using any virtual environment copy and paste the following command inside your command line before pressing enter.

Cool, we’re now all set up to start coding and creating our API requests. So go ahead and create a dedicated folder where we’ll store the code for our project. Here is a basic example, but feel free to use whichever template you’re most comfortable with.

From there, let’s open our python IDE and create our first code script that we’ll call function.py, in which we’ll code as functions all the API requests that we need to make to the Santiment API. The idea here being to keep things organised.

Alright so first stop, let’s create a function to request from Santiment the ETH historical price using the guidelines provided by Santiment in their documentation:

As you can see it is pretty straightforward and pretty much speaks for itself. So let’s try it out now in order to check that everything is working.

So first we’ll need to import a few packages among which datetime and sanpy.

Alright, and from there, let’s us do a basic testing of this first function:

And it works as expected, as you can see from the above illustration extracted from the Spyder variable explorer.

Alright, so now that we did the first example, we’re basically going to reiterate the same process for each case and create a function for each of our metrics.

Marketcap Function

Network Growth

⚠️⚠️

In the following cases given that we only want those metric for the current date, there is no need for a start date and an end date and can instead use here a unique date input that we’ll use both as “from_date” and “to_date”.

⚠️⚠️

Current Price

Current Volume

Daily Active Address

Token Circulation

Velocity

Social Volume

Top 10 holders holdings

Dev Activity

Github Activity

⚠️⚠️

Important note: Given that we are using the free Santiment API plan here, for some metrics we don’t have access to the latest value and view ourselves limited to only being able to request at most last month values. So it’s not ideal but given that the goal of this tutorial is just to learn how to create an overall data architecture it is not really critical here.

List of restricted metrics: Circulation, Velocity, Social Volume, Amount in Top holders, Dev activity, Github activity and Network growth.

⚠️⚠️

Alright and that’s it we have now at our disposal all the needed functions to request all our metrics from the Santiment API. So if you want to test it for yourself, here is the full test code:

So congrats, you made it through this first part of our DevOps tutorial! 🥳🥳

Next time, we’ll spin up our cloud server on Digital Ocean, create our PostgreSQL database and write our main code script calling those python functions in order to populate our database so stay tuned and happy coding in the meantime.

Take care 🖖

N.B As per usual full code available here on Cybergen Lab Github repo

Bebop

Following its recent soft launch over the summer to an exclusive set of whitelisted address on the Ethereum network, Bebop has now released its public mainnet version on Polygon coming with a really well developed UI and some novel features such as the one-to-many or many-to-one services enabling users to seamlessly consolidate a multi-token portfolio into a single token or inversely spread their holding across multiple tokens. Furthermore, leveraging the expertise of its backing partner as a professional market maker, Bebop made the choice of not becoming an automated market maker and ensure its platform liquidity through the more than 60 liquidity platforms offered by Wintermute which comes as interesting choice at a time where the yield appetite of DeFi users is definitely on the rise.

Rubic

Multi-chain swaps protocol and decentralised exchange Rubic has lost over one million worth of tokens after attackers gained access to the private keys of an administrator’s wallet most likely through a malicious software. Consequently to this hack and of the selling of the coins by the hacker, the RCB lost more than half of its prior value and still hasn’t recovered yet despite the recent core team offer to the hacker promising up to 20% of the RCB stolen as a bug bounty and no further legal action against the return of the remaining 80% RCB stolen.

Aave

The Aave community recently approved the Matter Labs’ proposal to deploy the decentralised lending protocol Aave on its Ethereum scaling product zkSync at a very large majority. However, this recent vote is for now only enabling the deployment of Aave to zkSync’s testnet. Indeed, Matter Labs will need to propose a new vote before being able to operate mainnet deployment.

Web3

IOTA

TanglePay, IOTA’s self-custody wallet recently announced a partnership with the Mises browser in order to enable users to profit from TanglePay wallet features both on desktop and mobile while using Mises.

Exodus

Moving forward on its effort to support an ever growing number of chains and offer the highest possible flexibility to its users, exodus one of the leading self-custodial crytpocurrency software platform recently announced the addition of the BNB smart Chain to its Exodus’s browser-based Web3 wallet.

Flux

Flux, the frontrunner in building decentralized infrastructure to power Web3 development, today announced the launch of Jetpack 2.0, a system update enabling easier and cheaper deployment of decentralized applications (Dapps) onto the Flux decentralized cloud. Additionally, Jetpack 2.0 also brings a variety of new features, including an improved Dapp registration and management process as well as direct fiat payment and settlement services.

Ecosystem

Ripple vs SEC

In a surprising turn of event, crypto exchange Coinbase which was among the first to halt trading of the XRP token following the filing of the SEC lawsuit against Ripple recently filed an amicus brief in the ongoing lawsuit between the SEC and Ripple Labs supporting Ripple Labs and highlighting the lack of clear SEC regulatory guidelines over the past couple of years.

Japan

NTT Docomo, Japan’s largest mobile operator with over $40 billion in annual revenue, recently partnered with multichain smart contract platform Astar Network to accelerate the Web3 implementation in the country through the build-up of a dedicated consortium giving to individuals and corporations the ability to utilize tokens for governance.

Market

• BTC     $18,576.50

• ETH     $1332.40

• BNB     $330,97

• ADA     $0.37

• SOL     $23.89

FTX ventures

FTX Ventures, the venture arm of FTX recently operated its first Web3 social media related investment through its participation for an undisclosed amount in a recent funding round held by Aave’s social media graph Lens Protocol.

Fordefi

Fordefi, a financial technology and software company, today announced an $18 million seed round led by Lighspeed Venture Partners and Alameda Research in order to further support the development of its newly launched institutional MPC wallet.

Today we’ll start introducing a pretty powerful analytical tool, called Dune Analytics largely used all throughout the space and enabling power users to freely and easily access on-chain data through simple SQL queries in order to create dedicated analytics dashboard supporting market research.

So to do that, we’ll create the below dashboard analysing a set of key metrics of the Chainlink ETH/USD data feed in order to learn how to query data through Dune analytics and also present those data using the different types of modules offered by the platform (counters, graph, tables …)

Alright so let’s get right into it, first if you haven’t already created one you’ll need to create a Dune analytics account using the following link.

Once you’re set you should be met with the following homepage upon connecting to the platform.

From there click on “New query” in order to get redirected toward the query builder.

There as shown on the previous captcha we are going to be met with 3 main components:

Component 1 — The query section where we are going to write our SQL queries

Component 2 — The Query result section where we’ll be able to visualize and fine-tune the visual rendering of our queries (tables, graphs, …)

Component 3 — The table section listing all the available Dune Analytics tables per integrated network.

Alright so let’s start building our first component here and create our SQL query for the number of requests made to the Chainlink ETH/USD price feed over the last hour. First we need to get the address of the Chainlink Price feed contract on the Ethereum mainnet that you can find here.

Chainlink ETH/USD address: 0x5f4ec3df9cbd43714fe2740f5e3616155c5b8419

Then from there,we can start building our query.

So first we need to extract all the requests which interacted with the Chainlink contract over the past hour. So to do that, we’ll use the ethereum.traces database allowing us among other things to extract the address of the requesters and use the COUNT() SQL function in order to obtain the overall number of requests per requester.

From there we need to calculate the overall sum of total requests over the past hour. So to do that we’ll need to fine tune a litle bit our code and encapsulate our previous code inside a table called here table1 in order to be able to use a second table calling table1 and be able to apply the SUM() function over our request_nb column to obtain our total request number.

Alright so now that we have our value, let’s create a new visualization in order to get that counter view that we want. So first go ahead and save your new query. Then once it’s done click on “New visualization” and select Counter type before clicking on Add Visualization.

From there feel free to use the names and style that you want or if you want to follow strictly what I did enter the parameters showned below.

When you’re ready, click on add to dashboard and click on the add button linked to the dashboard your willing to use.

And here it is ! If you go back to your dashboard you’ll see that we created our first live widget, on our dashboard 😃

Alright so now reiterating the same process we could manually create two new queries and go through all our previous steps to create the daily and weekly request counters.

However, it would be cumbersome and Dune Analytics allows us to create similar queries in a much more clever way so let’s just use it 😉

So first, let’s get back to our previous query and click on the fork button on the upper right part of the screen.

As you can see, we’ll get automatically redirected to a new copy or fork of our previous query enabling us to use right off the shelf our previous work.

So from there first, we’ll save this new query as our daily counter and change accordingly our time specification in our SQL queries before adding this counter to our new dashboard.

And then reiterating the same process, we easily create our weekly counter as follows.

Alright so now let’s move on to create our first table, showcasing the latest ETH/USD price feed requests. So here we want to be able to show 5 key informations:

• Time of the request

• Address requesting the ETH/USD price

• The gas limit used

• The actual gas price paid for the request

• The transaction hash

So first, let’s fork our initial query. From there as you can see by looking at the ethereum.traces dataset details, we already have at our disposal all those informations.

As such, the only thing that we need to do here to obtain our table, is to once again fork our initial query and fine tune it in order to extract all the needed metrics.

From there , as done previously we we need to save this new query and create a new visualisation in order to incorporate our table inside our dashboard. The only difference here being that we’ll go with the table visualisation.

From there again, feel free to use any style or title you want and remember to add this new element to the dashboard by clicking on the add dashboard button.

Alright so now moving on to our other counter, corresponding to the daily gas costs, here it is again pretty straightforward so try it for yourself before reading the rest in order to try it out for yourself and see if you start to get a hang of it.

Solution

Here as previously we’ll fork our initial query, however this time we don’t want the sum of all transactions but the average gas cost over a day period as such we’ll use here the AVG() function as follows:

Observation: Here given the inner limitation of Dune analytics we cannot only truncate our set of data in order to obtain solely the current date data through using CURDATE() so in order to tackle this issue we’ll use here the following work around consisting to order our extracted dataset by descending time order and then only keeping the first value using LIMIT.

From there as per usual use the counter visualisation and add it to your dashboard.

Alright so now let’s get to our graph visualisation, representing the evolution of the average gas cost over the past 14 days. To do so, let’s start by first fork our previous gas cost query. From there just change the interval day from 1 to 14 and here you go, you end up with the following table summarising the average ETH/USD query gas cost for each day over the past two weeks.

From there click on new visualisation and choose Area chart.

And here it is! You have a brand new live graph chart exhibiting the evolution of the gas cost over the past 14 days.

Alright, so now let’s create our last component and create our table showcasing the 10 main biggest ETH/USD price feed requester for the current day. So first, let’s fork our initial query.

The first thing that we need to do here is to work around the little limitation of Dune Analytics preventing us to only have value from the current day without yesterday’s value. Indeed here, if we only use the COUNT() function and sort our table with by the number of requests we’ll end up with the following result which is not that what we want.

As such to avoid this situation, a quick work around is to couple our previous request number ordering with another ordering applied on the time column as follows:

Alright so from there, even though we could stop here, it appears interesting to change the requester address with their real name whenever possible. As such, to do so, let’s head over to etherscan. There, using the contract address from our table let’s search the owner of the \xcf7fe2e614f568989869f4aade060f4eb8a105be contract.

Note: It is mportant to be aware that as per convention Dune analytics replaces the initial 0 of each Ethereum address by “\” as such when using Etherscan we have to be cautious to reformat the address into 0xcf7fe2e614f568989869f4aade060f4eb8a105be.

Furthermore, finding the owner of the contract might be a bit tricky at times and might even necessitate in some instances to either browse a bit around Etherscan or Google to find the contract owner.

However, in our particular case here, it appears as you can see pretty straightforward as shows the below Etherescan where we can easily spot that this contract corresponds to the ENS domain protocol.

Additionally, if you want to double-check on that point, one way to do so is to extract in Dune analytics the latest transaction hash, select those originating from that particular contract address and then go check the internal transaction of this transaction in etherscan to see if this contract is indeed used in the suspected context.

Example for the 0xcf7fe2e614f568989869f4aade060f4eb8a105be ENS domain contract:

Used transaction hash: 0x12cb364247f1fd1c93bbfb255c238ed4e9ea039482248a3ae5866d51a92fd130

Alright so from there once we have all our corresponding names for each address let’s integrate them in our table. To do so, we’ll have to refine a bit our code and as before incorporate our current existing code in a table that we'll call table1 in order to then be bale to call it in through another table and apply a set of transformation on our requester_address column using the WHEN argument allowing us to replace our current Ethereum address by its corresponding human readable name.

And from there you should be able to obtain a table with much more understandable names

Observation: In some instance, it is just not possible to find the contract adress owner so don’t sweat it and just put the reformated contract address for everyone to see in your table. Furthermore, given the used SQL function if a new address appears the following day in your table, the request origin will show a blank so I’ll let you fine tune that part as a small exercise if you want to have a better polished dashboard version.

Alright and after all that by just adding this new component you should have on your dashboard all our needed components. So from there just go ahead and click on the edit button located at the top right of your dashboard in order to be able to move things around and reformat the visual design of your dashboard as you prefer.

Note: If you want to create custom widget as the one showing the CyberGen Lab logo just just click on Add text widget and use the set of available markdown.

And that’s it ! Congratulations you made your first Dune Analytics dashboard 🥳🥳

So as always don’t hesitate to build upon that, create your own dashboards on other projects and have fun with the plaftorm 😃

Until next time, see y’all 🖖

Resources

Link to Chainlink ETH/USD price feed dashboard (Ethereum mainnet):

https://dune.com/cybergenlab/chainlink-ethusd-feed

Link to Chainlink ETH/USD price feed dashboard (Polygon mainnet):

https://dune.com/cybergenlab/polygon-chainlink-ethusd

Furthermore, from a pure networking standpoint, most PoW network are also starting to face a fair number of issues trickling down from their ever-growing mining process cartelization around a small subset of miners investing massive amount of CAPEX in order to spin up highly efficient and specialised mining facilities pricing out small casual miners out of of the ecosystem and creating a de facto a massive barrier of entry for any newcomer.

As such, in the light of this potential future regulatory breakdown on PoW network it appears interesting to start analysing other viable alternatives such as Spacemesh aiming to offer a new form of decentralised payment relying on a novel form of consensus algorithm called Proof of SpaceTime leveraging miners available disk storage space.

Spacemesh Overview

Spacemesh is usually advertised by its core project team as the natural evolution of PoW decentralisation payment network into a better and more efficient form enabling fairer token distribution and lesser energy consumption. Nonetheless, it appears important to bear in mind here that no first generation PoW blockchain ever truly succeeded to become viable decentralised payment networks (e.g Venezuela) and for the most part never got past the store of value use case.

Else relatively to its technical attributes, the Spacemesh protocol is most well described as a blockmesh protocol leveraging a custom proof of Spacetime consensus algorithm and a dedicated mesh network architecture avoiding the centralisation and energy consumption pitfalls of PoW protocols while offering at the same time a higher degree of token and network distribution.

Spacemesh Architecture

The Spacemesh protocol infrastructure is built on top of four core components each maintained separately but working in concert to enable the broader support of the Spacemesh network and ecosystem.

• Go Spacemesh — Open source codebase implementing the bulk of the Spacemesh core protocol and enabling each miner to run a protocol-compatible full node as well as a mining node on a variety of different systems and architectures

• PoET server — Web service enabling the implementation of temporality inside the Spacemesh network.

• Proof of SpaceTime (PoST) — Collective set of consensus algorithms employed simultaneously to ensure the build-up of a Spacemesh ledger implementing an ordered BFT canonical view of blocks.

• Spacemesh App — GUI-based desktop application acting as a wallet and running a Go-spacemesh full node instance in order to enable users to mine.

Spacemesh Design

PoW network, such as Bitcoin, usually tackle the Sybil attack problematic (where one entity secretly create a large number of miners) through the implementation of a computing intensive process leveraging miner’s electrical consumption cost as a scarce resource in order to impose an implicit limit on the number of nodes that a single actor can realistically spin-up.

However, as mentioned above despite being extremely robust from a technical standpoint, this solution is also extremely energy intensive. Consequently, Spacemesh is replacing Proof of Work with a novel type of consensus algorithm called Proof of SpaceTime (PoST) allowing miners to use disk space rather than computation as the scarce resource for preventing Sybil attacks.

How does it work?

Technically speaking let’s take the example of Miner A willing to pledge 500GB of disk space to the Spacemesh network to start mining. First, Miner A is going to go through a phase known as the init phase during which the network is going to require her to perform a one-time Proof of Work process in order to fill up her 500GB of storage with cryptographic junk.

Once, this phase is done, our Miner A is then set to start mining on Spacemesh and is going to be able to prove its eligibility for taking part in the mining process by just sending prior to each mining period a proof of its storage allocation, also known as activation transaction (ATX), build on top of the stored cryptographic junk.

How to make sure that miners effectively allocate space to the network between two activation transaction?

One of the issue with our previous process is that our Miner A could effectively perform the one-time proof of work process in order to be able to start mining and then supress the process output before reprocessing it right before the next period putting us back effectively in the situation where the scarce resource is not anymore the available disk space owned by Miner A but again its processing power leading us straight back to our previous PoW situation. As such, in order to avoid this problematic and enforce the disk space as the sole usable scarce resource, Spacemesh is incorporating the time primitive inside it’s ecosystem and more particurlarly in the build-up of each activation transaction in order to ensure that Miner A indeed allocated continuously her 500 GB to the network between each activation transaction.

How is time integrated in the Spacemesh protocol?

In order to implement time inside its mining process, Spacemesh is leveraging a cryptographic primitive called Proof of Elapsed Time (PoET) providing a proof that a sequential work cycle has been performed and thus that a given period of time has elapsed.

Furthermore in the case of Spacemesh, given than what is needed is merely a proof that a certain amount of time has elapsed there is no need for every miners to perform this sequential work themselves as it would defeat the initial purpose of Spacemesh to avoid continuous CPU work. Indeed, here it appears sufficient to have several PoET instances shared among multiple miners in order to minimise the overall electrical cost especially since each miner can easily check the integrity of the proof send by the PoET server and used another PoET server in case of malicious behaviour.

Consensus in Spacemesh

On the contrary of PoW networks enforcing a racing mechanism between miners where the first miner to produce and communicate a valid block to the network earns the right to produce the current block of the chain and where each block are produce one after the other. In the case of Spacemesh, multiple blocks get created simultaneously and every miner that expands sufficient space-time resource is deterministically eligible to generate a block.

As such, given its inherent lack of block ordering and randomness features normally generated by the racing mechanism, Spacemesh needs to implement a way of ordering newly creating blocks in order to form its canonical ledger as well as an external source of randomness in order to make difficult to predict who will be eligible to generate a block

Spacemesh block ordering

Spacemesh employs simultaneously two consensus mechanisms in parallel to determine the canonical set of blocks at each layer:

• Hare protocol — Byzantine Fault Tolerant consensus algorithm

• Tortoise Protocol — Slow vote based mechanisms requiring each node to count the votes “for” and “against” each previous block and tallying these votes to eventually achieve consensus.

Tortoise protocol

The Tortoise protocol is the mechanism by which the Spacemesh network achieves final consensus on the set of blocks and transactions that form the canonical ledger.

Technically speaking, each time a miner produces a new block, they include in that block a “votes” field that lists one or more previous blocks that the miner also considers valid at the time the block is produced.

→ Each time, a new block links to a given older block, the vote tally for that older block increases by one. On the contrary, any block generated after a given older block that doesn’t vote for that block is counted as a vote against the block.

Furthermore, the Tortoise protocol is using a majority-rule fashion such that any block with a net tally greater than the irreversibility threshold becomes part of the canonical ledger.

Observation: Currently each vote is weighted proportionally to the amount of space-time resources it represents, e.g, votes cast by a miner that has committed 200GB count twice as much as votes cast by a miner that has committed 100GB to the protocol. As such, given the current lack of upper storage limit this design feature could represent a critical risk to the network if not fixed before mainnet launch given that a cartel or single massive miner could seize control of the Tortoise protocol voting and by extension of the canonical ledger.

Why the need for two consensus protocols?

Despite being extremely robust, the Tortoise protocol is also pretty slow to run and cannot run on the most recent layer since there are not yet any newer blocks voting on these blocks. Therefore, Spacemesh is using a quicker consensus mechanism in order to bootstrap the Tortoise protocol called the Hare protocol which purpose is to allow each node to quickly determine the set of blocks in the layer to be voted on by all honest miners.

Hare protocol

The Hare protocol, run once per layer, is a BFT-compatible algorithm achieving consensus in four round and levergaing the participation of a randomly selected subset of available eligible block producers.

Technically speaking, at the beginning of each round, each miner draws through the use of a Verifiable Random function a role that tells it whether it’s active (i.e participating) or passive (i.e just observing) in this round.

If the Verifiable Random Function (VRF) output passes some threshold depending on the number of total active miners then the miner is active else it remains passive for that round.

Hare protocol flow

The protocol takes place over four rounds, which are preceded by a pre-round:

• Pre-round — Each active participants shares their current view of blocks that are valid. At the end of the round, each then factors in the views shared by other participants and updates their view by removing blocks that didn’t receive enough support from other participants.

• Status round — Each active participant broadcasts a status message reporting its updated view.

• Proposal round — Each active participant broadcasts a proposal to the group, based on the results of the previous round. One of these participants will be randomly chosen to be the leader.

• Commit round — Each active participant independently determines who was elected leader, reviews the proposal from this leader, and signal its willingness to commit to it to the group. By the end of this round, each participant that received a valid proposal from the leader and a sufficient number of commit messages from other participants creates a commit certificate including all of this information.

• Notify round — Each active participant holding a commit certificate broadcasts it to the group. Then, if a sufficient number of commit certificates are received from other participants, the protocol terminates and each participant knows the proposed canonical set of blocks.

Finality in Spacemesh

Contrary to PoW network the Spacemesh goes through two distinct phase of finalisation. A first phase corresponding to a temporary canonical consensus produce by the Hare protocol and a second stage corresponding to the final canonical consensus once the Tortoise protocol reaffirm the Hare proposed canonical order.

Note: In the case where the Tortoise reject the proposed canonical order output by the Hare protocol, both rewards and transactions are rolled back and reapplied based on the new set of valid blocks.

See Appendix for greater details on Spacemesh block creation and transactions structure

Spacemesh features

Beacon

Spacemesh runs a beacon protocol to generate a random value at the beginning of every epoch. In order to take part in this process, a miner must satisfy the following conditions:

• Be online

• Be synced and having listened to network gossip for at least 2 layers

• Be an eligible miner since at least epoch N-1

Technically speaking the beacon protocol is essentially a simplified Tortoise consensus protocol where each sampled miner first propose its own seed of randomness before the casting of all votes and the reaching of a global network consensus on the beacon value to be used in the next epoch.

Note: Having the correct beacon determines weather a miner can generate proposals and participate in the Hare consensus protocol to earn mining rewards.

Self-Healing

While the Tortoise protocol is very secure it is also fragile in the sense that its security rely solely on the assumption that the protocol holds all the way from genesis. However, over a long enough period of time, the likelihood of some events to occurs and cause the protocol to faill approaches one. As such, in order to easily recover, Spacemesh includes a feature known as self-healing through which all nodes agree at every layer on a random coin-toss in order to easily make a decision regarding a block in the case where the margin of vote casted for and against this latter is very narrow.

SMESH

Future high-level programming language that will compile to SVM WebAssembly code and enable developer to easily build on top of the Spacemesh ecosystem and integrate smart contract logic inside their dApps.

Spacemesh Governance

While being fully open source, the governance of the Spacemesh protocol still remains pretty much centralised around the core team relatively to the protocol development and other critical aspects of the projects such as the coin issuance schedule.

Furthermore, it is important to note that there is currently no plans or discussion for a potential future on-chain governance of the upcoming Spacemesh Mainnet which could appear to some a bit worrying given the current track record of the core team and the numerous development delays suffered by the project originally set to hit market years ago.

Spacemesh cryptoeconomics

As every other layer 1 blockchains aiming to become viable decentralised payment networks, Spacemesh economical design is revolving around a native token called MESH whose two sole purposes are:

• Facilitating token denominated network reward for active agents supporting the network

• Acting as a payment vehicle between users.

Note: The network being still in its testnet phase there is for now no actual reliable market metrics available.

Token Distribution

Accordingly to its core goal of ensuring a fairer token distribution, the core team avoided any pre-mint mechanism that would have created a front-loading situation for early adopters and innovators and hinder any future token distribution to the rest of the ecosystem.

Furthermore, from a token distribution standpoint, similarly to Bitcoin, Spacemesh is using a custom gradual decay pattern enforced after each layer in order to implement an overall token issuance half-life of 29 years. However, on the contrary of PoW network where rewards are attributed solely to the block producer, in the case of Spacemesh given that multiple blocks get produced at the same time, all fees and network reward get pooled together during each mining period before then being proportionally reallocated to each participating miner up to the extent of work effectively performed across the period.

Observation: As it stands, it appears that despite its claim of ensuring a fairer token distribution Spacemesh is here falling a bit short given its lack of innovation from a token emission standpoint compared to other existing PoW networks as well as its current network design which would in the current state of things inevitably lead to a token front-loading situation benefiting big miners right after mainnet launch due to the cryptoeconomic choice of allocating proportionally more mining slots to miners allocating more space to the network without any limitation.

Spacemesh Ecosystem

Spacemesh team

Tomer Afek, Co-founder, CEO

Extensive prior experience in M&A and finance as well as in the tech industry with various ventures in the media and and web publishing sectors.

Rami Kasterstein, Co-founder

Web entrepreneur and venture capitalist involved in several Web3 media and software related ventures.

Aviv Eyal, CPO, Co-founder

Blockchain specialist with extensive experience in mobile gaming and Web3 consulting.

Tal Moran, Chief Scientist

Blockchain specialist, computing science researcher and theoretical cryptography professor at the Reichman University.

Ecosystem current state

As of now given the current state of development of the project, there is no ecosystem per se developed around the Spacemesh protocol. Furthermore, in the light of the numerous delay in the core project development witnessed over the past threeyears, it appears sound to say that the development of the ecosystem around the core protocol will most likely require several additional years.

Roadmap

As of now the core team is currently working on the testnet version of the Spacemesh protocol and aims to release its mainnet version later in December. However, in the light of the numerous delay witnessed since the initial launch date set back in 2018 it is important to remain cautious as the team might pushed back again the launch of its mainnet toward later in 2023.

Conclusion

Given the current Spacemesh mining process rewarding miner proportionally to their allocated disk space without any max cap and the cryptoeconomic choice of using a decay pattern the claim relative to a fairer token distribution appears for now somewhat misleading given that the nature of the network itself will inevitably create a front-loading situation for professional miners in the early days of the network if no max storage cap is implemented until then. Additionally, the proportional weighting of miners votes inside the Tortoise protocol appears to also be another critical reason why the implementation of a max cap would be a critical need given the risk of Sybil attack from an entity with extensive disk-space resouces upon mainnet launch.

Additionally, the protocol claim relative to becoming the main decentralised payment network protocol seems for now quite doubtful given the current protocol technical limitations compared to other more centralised alternatives and the fact that potential users will most likely not switch towards a more decentralised alternative if not at least as efficient from a settlement time standpoint as the ones they’re currently using.

So to conclude, despite the fact that this protocol is proposing an interesting alternative network structure that could bring new opportunities for miners through its novel token distribution and network architecture it appears that for now Spacemesh still need more time to further develop and fine-tune its core network and cryptoeconomic design before being able to be considered as a viable upcoming alternative to existing PoW networks such as Bitcoin.

Appendix

Spacemesh uses the the account model for storing value, meaning that that users are encouraged to reuse accounts for multiple transactions and that from different transactions increasing the account balance become fungible and indistinguishable from on another.

Note: Each account store a transaction counter in order to avoid any possiblity of replay attack inside the network.

Transaction Structure

The transaction data structure contains the following elements:

• Recipient’s address

• Amount to transfer

• Amount of the fee to be paid

• Transaction counter

• Signature

Note: Transaction do not mention explicitely the sender’s address given that each transaction is signed using the private key of the sender’s account from which the public key can be easily derived.

Transaction processing

Each miner receive each incoming unprocessed transactions locally over GRPC or via network gossip and automatically save those in its mempool after performing a serie of basic check ensuring the contextual validity of the transaction. Furthermore, the miner also further gossip the transaction in order to ensure its propagation to all peer in the network.

Note: A transaction is deemed contextually valid if at the moment when the transaction is applied to the global state, the following condition apply:

• The transaction appears in a contextually valid block

• The origin account exists

• The counter on the account matches the transaction counter

• The account balance is greater than or equal to the transaction amount + fee

Transaction ordering

The transaction ordering in Spacemesh is defined as follows:

• Blocks in layer n comes before those in layer n+1

• The IDs of all contextually valid blocks in layer n are listed in ascending order

• These block IDs are concatenated and hashed

• The hash sum is used as the seed for a Mersenne Twister

• A Fisher-Yates shuffle is performed on the list of block IDs using the output of the Mersenne Twister

• Transactions from the ordered blcoks are then applied in the order they appear in each block ignoring duplicates.

Disclaimer: All information/documents contained in this article rely solely  on my personal beliefs, and do not constitute professional investment advice.

Be careful in your investment and do not invest more than you can afford to loose.

Arco Protocol

Adding on the to disastrous launch of the Aptos network last month, the Arco Protocol a new cross-chain decentralised finance platform developed on the Aptos blockchain recently experienced a disastrous fundraise DEX offering which led to a temporary shutdown of the project and the loss of key industry partnerships (Celer Network, Wormhole). At press time, the core team is polling the community in order to decide whether the funds received should be returned, kept or if the project itself should be handed over to the community. Nonetheless the future for the protocol appears pretty bleak as the large majority of users are currently requesting full refund.

Blockchain.com

In response to the recent association between BitOasis and Mastercard aiming to bring digital assets to population in the Middle-East and North Africa region through a series of crypto card programs, Blockchain.com and Visa recently revealed a new key partnership which will enable US residents to pay for daily expenses using their crypto or cash balance even though from a US tax revenue standpoint this new form of debit cards still raises a lot of questions.

Team Finance

Team finance recently announced a successful $14.5M exploit of its platform and temporarily shut down all activities in order to prevent further exploits and try to get in touch with the hacker for a potential bug bounty payment. Technically speaking, the hack took advantage of a vulnerability of the Uniswap V2 to V3 migration function which hasn’t been spotted by the team during the testing phase nor during the previous external code audits raising again the question around the need for better overall code auditing and code standardisation if blockchain protocols are ever to be globally adopted.

Web3

MetaWork

MetaWork a communication and collaboration operating system for Web3 creating new standard of messaging and notifications for teams, enterprises and DAOs recently announced a new key partnership with Spheron which will enable it to build its web app in a fully decentralised manner using Spheron’s decentralised storage network.

Binance

Earlier last week, Binance announced the release of its native oracle service aiming to enable smart contracts to run on real-world inputs and outputs starting with the BNB chain ecosystem and its over 1,400 application. Furthermore, being chain-agnostic, this new oracle service will in-time integrate with other additional blockchains.

Zerion

Zerion a Web3 investing tool and crypto wallet provider which launch its native wallet earlier this year with the goal of attracting seasoned crypto users recently closed an additional $12.3 million funding round in order to continue developing additional features (pre-trade verification, vetted cryptocurrencies verification…) and become a viable alternative to Metamask for degen users.

Ecosystem

DeFi regulation

Vitalik recently publicly took part in the current debate around DeFi regulation in the US and highlighted through an extensive twitter thread that in his opinion the blockchain industry is still not quite ready for fully integrated with mainstream finance and should take more time to mature in order to not fall victim of bad regulations that would intrude on how crypto work internally.

US regulation

In line with the recent commission bid to gain more regulatory oversight over the crypto industry, Commodity Future Trading Commission’s Christy Goldsmith Romero recently pointed out that the collapse of the Terra ecosystem and its flow-on effect was a perfect example of why the agency should be given additional authority to regulate this new upcoming industry given how similar contagion risks within crypto market are to those experienced in the traditional financial system.

Market

• BTC     $20,524.50

• ETH     $1592.17

• BNB     $341,42

• ADA     $0.40

• SOL     $32.90

Sei

Sei, a Layer 1 blockchain and Alpha Venture DAO a renowned Web3 venture builder recently unveiled a new incubation program called Alpha Incubate Batch 2 aiming to support the growth of new DeFi projects.

Meta

Meta joined forces with fashion company L’Oréal and French college HEC to support startups developing Web3 technologies, including avatar development through a future accelerator program geared toward facilitating creativity in the Metaverse.

Reap

Reap a Hong-Kong based start-up recently closed a $40M funding round aiming at developing infrastructure to help facilitates payments between Web3 projects and traditional businesses.

Why using Pi network?

• Enable casual users to earn tokens through simple daily KYC procedure on the Pi mobile app

• Better throughput than PoW network such as Bitcoin thanks to the leveraging of the SCP

• Fair and meritocratic token distribution proportional to the daily network support of each active participant

Pi Network architecture

As mentioned above, the Pi network consensus algorithm is built atop the Stellar Consensus Protocol designed by André Mazière and currently implemented within the Stellar Network. However, at the difference of this latter relying on a set of trusted nodes run by well-known corporations such as IBM and the likes, Pi network made the architectural choice of relying solely on a decentralised network of nodes composed of individual devices ranging from mobile phones to computers.

Furthermore from a design standpoint the Pi blockchain is leveraging four core network roles:

• Pioneer — Users of the Pi mobile app who simply confirm that they are not bots on a daily basis through connecting and signing on the app.

• Contributor — Users of the Pi mobile app contributing and providing a list of pioneers she knows and trusts enabling in aggregate the build-up of a global trust graph.

• Ambassador — Users of the Pi mobile app introducing new users to the app

• Node — Users that are pioneer, contributors and also running the Pi node software which runs the core SCP algorithm taking into account the trust graph information provided by the contributors.

Pi Features

Currently the project being still in its pre-release phase, the core team hasn’t developed any additional features outside of the core blockchain stack. However, as per the whitepaper, the core team is planning the future development of a full suite of features building-up on the current existing Pi mobile app:

• Pi attention marketplace — Scare Instagram like social media channel open to any pioneer to post their content and further build-up the community liveliness with debates, pools, exchange of media …

• Pi’s Barter marketplace — Development of the existing Pi mobile app in order to enable each pioneer to sales goods and skills to other member of the Pi ecosystem.

• Pi App store — Development of a dedicated app store enabling builders to bootstrap their dApps launch using the existing Pi community.

Pi Governance

Mindful of the necessity of having a lot of flexibility in the development of such a protocol, the core team has assembled a governance scheme evolving with the development of the Pi ecosystem and user base.

As such, in the first stage of development while the overall user base remains under 5M members, the Pi project will used a provisional governance model resembling off-chain governance models currently employed by other protocols such as Ethereum or Bitcoin in order to enable the core team to guide at best the development of the protocol. Then, following this first stage, once the Pi ecosystem will reach its target of 5M members, a provisional committee will be formed based on prior active agents contributions and be charged with the responsability of leading the future development of the protocol.

Pi Cryptoeconomics

Main token metrics

The network being still in its early stage of development the Pi token is not currently listed on any exchanges nor tradable for any currency. Nonetheless, it is interesting to note that in order to bootstrap interest for the project the team launched a test version of the token which will become later on redeemable for live Pi token once the network will reach its mainnet stage in order to reward early supporters of the project.

Note: In order to avoid any amlicious attack on the network during its pre-mainnet phase with agents spinning up multiple wallet address in order to perform parallel mining, the core team develop a really tight KYC process relying on manual verification from other active agents of the Pi network (video, picture, ID papers …)

Token utility

The design being still in the midst of profound development, nothing can be asserted here with absolute certainty regarding the full range of utility functions that the Pi token will indeed fulfill upon mainnet launch. Nonetheless, for now as per the project documentation it appears that the Pi token will at least fulfill the following core utility functions:

• Governance — Grants voting rights on governance vote

• Mining rewards — Grants proportional rewards to all agents actively supporting the network

• Fee payment — Enable users to prioritise the processing of their transaction in the case of high throughput on the network

Token allocation

As per the protocol documentation, the Pi network exhibits a max supply of 100 billions Pi tokens allocated as follows:

• 20 billion for pre-mainnet

• 45 billion for future mainnet

• 5 billion for liquidity pool

• 10 billion for foundation and community grants

• 20 billion for core team, vested based upon the percentage of coins unlocked at given time on the network (4 billions unlocked during pre-mainnet corresponding to 20% of the 20 billions tokens unlocked during pre-mainnet)

Observation: Extremely inefficient token allocation creating a worrying token problematic as well as a massive front-loading situation at the benefit of the core team given that as per the current token vesting schedule the team composed of roughly 30 people has received 4 billions tokens leading to approximately a stack of 130M tokens per team member against only a potential stack of approximately 571 tokens per active users if we take the last report of Pi active users boasting 35 millions active agents.

Token emission

The token emission policy of the network is governed by the following equation:

Total Max supply = Mining Supply (M) + Referral Supply (R) + Developer reward (D)

where:

The mining supply correspond to the aggregate amount of minted Pi token created for each new users joining the network up until the 100 millionth new user.

The referral supply corresponds to an additional protocol incentive minting a a fixed amount of Pi tokens as a referral bonus for both the referrer and its referee that gets reallocated equally to both parties over their lifetime on the network.

The developer rewards minted alongside each new Pi coin minted for mining or referral purposes in order to build a protocol treasury growing proportionally to the size of the Pi network and allowing the future funding of the protocol development and grants program.

Pi Ecosystem

Pi Team

Dr Nicolas Kokkalis, Head of Technology https://minepi.com/team/member/1

Stanford PhD and instructor of Stanford’s first decentralized applications class; combining distributed systems and human computer interaction to bring cryptocurrency to everyday people.

Dr Chengdiao Fan, Head of product https://minepi.com/team/member/2

Stanford PhD in Computational Anthropology harnessing social computing to unlock human potential on a global scale.

Ecosystem current state

As of now given the early stage of development of the project, there is no ecosystem per se developed around the Pi network.

Roadmap

The roadmap published by the team is pretty opaque to say the least. Indeed even though it gives the major direction of the project there is no indication of the current state of the core development and no available github repo to audit the code implemented by the project raising again the problem of the opacity surrounding the project and casting somewhat of a shadow concerning the claim of future AI integration for the app users given the pretty basic state of the technical stack currently experienced by app users.

Pi network roadmap (as per the whitepaper):

Phase 1 - Design, Distribution, Trust Graph Bootstrap.

The Pi server is operating as a faucet emulating the behaviour of the decentralised system as it will function once its live. During this phase improvements in the user experience and behaviour are possible and relatively easy to make compared to the stable phase of the main net.

Note: All minting of coins to users will be migrated to the live net once it launches meaning that the livenet will pre-mint  in its genesis block all account holder balances generated during Phase 1, and continue operating just like the current system but fully decentralized.

Phase 2 - Testnet

Before we launch the main net, the Node software will be deployed on a test net. The test net will use the same exact trust graph as the main net but on a testing Pi coin. Pi core team will host several nodes on the test net, but will encourage more Pioneers to start their own nodes on the testnet.

Phase 3 - Mainnet

When the community feels the software is ready for production, and it has been thoroughly tested on the testnet, the official mainnet of the Pi network will be launched. An important detail is that, in the transition into the mainnet, only accounts validated to belong to distinct real individuals will be honored. After this point, the faucet and Pi network emulator of Phase 1 will be shut down and the system will continue on its own forever.

Conclusion

Despite being conceptually interesting from an architectural and network design standpoint, the questionable cryptoeconomic design of the Pi network creating a massive token front-loading for the core team as well as the overall opacity regarding the current development and state of the project are raising many red flags which will undoubtedly hinder the interest of potential investors in the future. Consequently, instead of a breaking new L1 protocol reap for future success it appears better to consider the Pi Network as a good proof of concept of what is possible to create using the SCP consensus algorithm and a good theoretical foundation for future similar protocols integrating better cryptoeconomic and governance design

Disclaimer: All information/documents contained in this blog rely solely  on my personal beliefs, and do not constitute professional investment advice.

Be careful in your investment and do not invest more than you can afford to loose.

Why using API3?

• No middle-man tax — Redirection of cryptoeconomic flow towards the API providers

• High level of transparency —  Cryptographically signed data by well-known API providers.

• Collaborative governance — Interesting leveraging of the DAO framework offering a large level of community power over the protocol development compared to other competitors such as Chainlink

API3 Architecture

API3’s network architecture is built-upon five core components:

• Airnode — Easy to set-up serverless oracle node enabling API providers to transmit proprietary data on-chain with little to no maintenance.

• Oracle Integration Specifications — Technical component enabling to define through a JSON object all the API specifications as well as the Airnode endpoints linked to API operations.

• Beacons — Continuously updated streams of off-chain data provided by known API providers.

• API3 market — Data feeds market place enabling to search, monitor and consume existing data feeds on a broad range of networks similar to the one developed by Chainlink.

• API3 staking pool — Staking pool acting as collateral for the payment of valid service coverage claim and enabling token holders to obtain representation in the API3 DAO and earn staking rewards for their support of the network.

Note: Interesting use of the staking pool as a protocol collateral enabling a cryptoeconomic incentivisation of active agents towards efficient protocol governance.

API3 Features

Despite being relatively new compared to other more established oracle protocols, API3 is already offering an interesting range of product bringing additional flexibility and features compared to what is currently available in the space:

• dAPIS —  Highly flexible data feed service enabling users to access general data-feeds or developed new ones with custom curation features (beacon numbers, …)

• ChainAPI — Intuitive off-the-shelf solution enabling API provider to seamlessly configure and deploy an Airnode integrated with  their API without the need of a dedicated in-house devOps team.

• QRNG — On-demand quantum random value generator offering a higher level of randomness than pseudo-randomness generation function such as Chainlink VRF.

API3 Governance

The API3 network is a community-owned protocol governed through a Decentralized Autonomous Organisation (DAO) enabling every API3 token holders to participate in the governance of the protocol proportionally to his token holdings.

The API3 DAO only votes on high-level parameters regarding core protocol mechanics and developments (roadmap, grants …) while more granular tasks are conducted through a custom hierarchical team structure in order to avoid unnecessary overlapping during the development process and  ensure that critical operations such as dAPI management are executed swiftly and based on expert opinion.

Governance flow

• Step 1 — Tasks get conducted through off-chain team of specialists appointed by the DAO through grants

• Step 2 — Once the task reach a scale that can no-longer be fulfilled by a unique team, a subDAO with its own set of affiliated off-chain teams is created in replacement.

API3 Cryptoeconomics

Main token metrics (10.21.22)

Source: coinmarketcap

Token Utility

The native API3's ERC20 token fullfill three core utility functions:

• Staking — Grants inflationary rewards for users staking token in the API3 pool

• Governance — Grants direct representation in the API3 DAO

• Collateral — Ensure financial service coverage backing against damages caused by dAPI malfunctions

Observation: It is critical for these three utilities to coincide as all governing entities must receive staking rewards for them to govern in a way that maximises usage and also have their funds used as collateral to ensure a responsible protocol governance minimising security risks.

Token Allocation

As of today the total supply of AP3 tokens is of  114,855,860 tokens. Out of this total supply, 100 million tokens were initially allocated in November 2020 during the initial token distribution on Mesa DEX and the remaining 14,855,860 API3 has been minted as staking rewards since then.

Initial token distribution breakdown:

• 30 million for API3 founders and team vested over three years with a six-month cliff

• 25 million for the API3 DAO to build the project's community and ecosystem vested over three years with a six month cliff

• 20 million for public investors unlocked after the initial Mesa DEX offering

• 10 million for API3 partners vested over three years with a six month cliff

• 10 million for seed investors over two years

• 5 million for pre-seed investors vested over two years

Token inflation

To secure the network through staking, API3 maintains an inflationary issuance of staking rewards. The staked tokens are primarily used as collateral in the on-chain service coverage fund. However, if the non-profit API3 DAO has excess revenue after subtracting all its costs, it use this excess revenue to buy API3 tokens that are afterwards burned. Similarly, any USDC left over from operations will be used to buy API3 from the open market and burn it.

Furthermore, the inflation rate is calculated using the staking pool size as a percentage of the total supply that is set by the API3 DAO. If the target is met, APR is decreased by 1% each week else APR is increased by 1% each week.

Note:  Staking rewards are paid out weekly, and are locked for one year after they have been paid.

API3 Ecosystem

API3 Team

Heikki Vanttinen: Co-founder, Strategy

Extensive prior experience in the blockchain space and more particularly in domain such as smart contract decentralised identity.

Burak Benligiray: Co-founder, Core technical team lead

Former Google scholar and CTO at CLC Group and Honeycomb with a prior experience in computer vision and artificial intelligence.

Saša Milić: Co-founder

Software Engineer, data scientist and cryptocurrency researcher with prior software development experience at Facebook.

Mason Burkhalter: Operations Lead

Extensive prior experience in Business consulting and Software development.

Ecosystem current state

• Airnode deployed on 13 chains and EVM compatible

• Multi-feeds data sources still in development.

• Over 150 data providers currently available

• Lack of traction on flagship products (more than 2/3 of QRNG requests still originates from Rinkeby testnet, ...)

• Little to no effort to attract new data providers to the ecosystem given the core team current focus on data curation quality

Key Partnerships

API3 X AmberData

Key partnership with Amberdata which enabled the development of a broad set of high-quality price data-feed on a small subset of EVM-compatible chains (Ethereum, Polygon, BNB, Avalanche and RSK). However, the sole focus on cryptocurrency prices still somewhat limits the potential use-cases of those API3 dAPIs.

API3 X Silta

Development of a new class of financial products leveraging API3’s oracle solution in order to develop credit score oracles as well as novel financial assets enabling physical infrastructure developers to use on-chain collateral.

API3 Roadmap

Disclaimer: All information/documents contained in this article rely solely  on my personal beliefs, and do not constitute professional investment advice.

Be careful in your investment and do not invest more than you can afford to loose.