funded
Spectrum.Network | Layer 2 for DeFi
Current Project Status
In Progress
Amount
Received
$260,000
Amount
Requested
$312,000
Percentage
Received
83.33%
Solution

Build a platform for natively cross-chain dApps based on a decentralized consensus protocol.

Problem

There’s no direct access to the liquidity of other blockchains for dApps. Moreover, there’s no decentralized way to transfer liquidity across different DeFi protocols. CEX is the only tool.

Impact / Alignment
Feasibility
Auditability

Spectrum Finance

3 members

Spectrum.Network | Layer 2 for DeFi

Please describe your proposed solution.

We created this proposal with the research and development purpose of the Layer 2 DeFi scaling solution that will solve cross-chain interoperability problems for developers and throughput and transaction fees problems for the DeFi application end-users. We call it Spectrum.Network. Let’s talk about everything in order.

1.The current state of DeFi

Classical DeFi applications such as Uniswap, Compound, etc. have shown promising results in regard to features and decentralization, but also revealed essential limitations of the approach which most present dApps are built upon. These limitations fall into two categories:

  1. Poor user experience;
  2. Poor capital efficiency.

Some examples of the features that fall into the “Poor user experience” would be long confirmation times and sometimes extremely high fees. And as for “Poor capital efficiency” this would be non-optimal prices, arbitrage, and Miner extractable value (MEV). All the things that slowly siphon users’ profits.

These issues are being addressed by developers of existing or classic Layer-1-based dApps to some extent, but the old approaches are limited in what can be done.

The most popular type of DeFi applications that are similar to Uniswap and ErgoDEX are built directly on a Layer 1 blockchain:

Image File

Classical DeFi protocol:

  1. Ties the performance of the dApp to the performance of a Layer 1 blockchain (e.g. Ethereum, Cardano or Ergo). Let’s not forget that decentralized blockchains are maintained by thousands of nodes which all have to run the same computations in order to confirm that a transaction is correct. This leads to the fact that the execution of complex smart contracts takes a long time, especially if the network is congested;
  2. Limited by the liquidity of the parent blockchain. At the moment, this problem is partially solved with the help of synthetic assets. But such a solution does not allow direct access to the liquidity of other networks;
  3. Does not allow you to swap native currency in decentralized and native manner. For example, to transfer your liquidity from ETH to ADA you have to use CEXs to reach your goal.

2. State of cross-chain DeFi

Cross-chain decentralized finance is a novel approach aiming to solve the above issues.

Rather than committing to a concrete single Layer 1 blockchain, cross-chain solutions abstract across several Layer 1 networks with a focus on interoperability and cross-chain liquidity aggregation.

True cross-chain DeFi is impossible without a solid Layer 2 solution that allows us to:

  1. Offload the burden of expensive transactions validation from Layer-1s;
  2. Validate cross-chain transactions faster and cheaper than other designs.

Image File

In order to implement a cross-chain solution, an interoperability layer is required. The problem of cross-chain interoperability can be reduced by transferring data among multiple blockchains. There are already a few existing solutions in the field. Let’s look at them and see why they are not satisfactory for cross-chain DeFi.

2.1. Custodial solution: Trusted Oracle

Cross-chain interoperability could be achieved with a “trusted oracle” that registers some event on one blockchain and performs the required action on the other. For instance, below is an illustration of a simple cross-chain swap:

Image File

Centralized oracles provide fast and cheap transactions but lack a key feature, decentralization. The liquidity of a protocol built on this approach is custodial, which is a centralized approach similar to CeFi when users deposit their funds to an exchange’s wallet:

  • A system is not sustainable when it depends on a single party;
  • If the oracle goes down unfinished swaps can appear frozen halfway;
  • A centralized oracle can censor transactions;
  • A malicious oracle can perform a man-in-the-middle attack by sending inaccurate data.

2.2. Semi-centralized oracle network

Another approach involves some sort of intermediate network of oracles facilitating the transfer of data among multiple blockchains.

Often, all funds transferred between blockchains are stored and distributed on special threshold wallets, which are generated by the participants of the intermediate network, thus they are controlled by a group of oracle operators.

This method is inherently similar to the first one, it is more decentralized, but less reliable, due to the fact that PoA or PoS is used with high collateral and a small (less than a hundred) number of nodes. This makes it impossible to achieve high decentralization and system security. But, at the same time, the system becomes inflexible. xDeFi protocols built on such networks turn into a distributed custodial repository of funds managed by a small group of people.

Image File

3. Spectrum.Network

Spectrum moves beyond the idea of cross-chain data bridges and implements a decentralized protocol for cross-chain computations. This assumes not only the transfer of data (assets, events, etc) among heterogeneous blockchains but also computations on this data, just like smart contracts on regular Layer 1 blockchains but with access to multiple blockchains at once. This also allows us to shift validation of complex DeFi smart contracts from Layer 1 blockchains.

Data from connected blockchains (transactions, assets, events) is aggregated along with Spectrum transactions into blocks which form a higher-order chain. Spectrum transactions are allowed to execute smart contracts that operate on data from the connected blockchain and can trigger on-chain finalization.

Image File

Spectrum.Network operates under an optimized Roll-dPoS consensus protocol, which was used in IoT-oriented blockchains such as where nodes are IoT devices, so the protocol is designed to support a large number of participants.

Our contribution to the existing evaluation of Roll-dPoS introduces CoSi — an efficient protocol for collective signing. Replacing the old signature protocol from Roll-dPoS with CoSi we get faster block negotiations (from O(n) in old Roll-dPoS to O(log n), where n is the number of validators).

The following properties allow the consensus to achieve a high degree of decentralization and security:

  • Decentralized operation of the protocol with a large number of participants (thousands of nodes), protected from compromise by collusion of a narrow circle of people;
  • Low cost of entering the protocol and high cost of compromise;
  • Tolerance to high network churn.

Image File

Roles in the Spectrum.Network are randomly assigned to participants via a lottery until the end of the epoch. The honesty of the chosen participants is achieved by economic incentives built on the prisoner’s dilemma from game theory, which states that it is more profitable for each participant to betray the attacker and receive a reward, rather than join the attacker and incur punishment.

Putting it all together

Spectrum.Network reveals the true potential of ErgoDEX. First of all it will allow quicker and cheaper transactions. Secondly, it will have cross-chain liquidity and interoperability out of the box. Not only bridges for cross-chain transfers of assets, but truly cross-chain pools for native assets, where on one side is native ADA and on the other is native ERG. And finally, Spectrum opens the door for more sophisticated DeFi protocols such as Decentralized Lending, Option Vaults and others, which are impractical to build on top of many Layer 1 blockchains due to current design limitations.

--

The code will be 100% open-source so anyone can contribute to the Spectrum.Network development.

Please describe how your proposed solution will address the Challenge that you have submitted it in.

Awareness & Understanding

High performant cross-chain Layer 2 Spectrum.Network will boost DeFi for all communities to scale borders of their research and irreversibly create cooperation flows.

Organisation & Governance

Our team plans to make not only an underlying technology for building cross-chain DeFi applications but also develop our cross-chain DeFi protocols on top of it, such as AMM, Order Book and Option Vaults. In addition, the existence of Spectrum.Network will make it possible to develop a DAO with more complex logic, including asset management from different networks.

Culture, Diversity & Inclusion

We are committed to the culture of open source development. Open source is the basis for the successful development and adoption of the blockchain industry.

Collaboration Tools & Platforms

Spectrum.Network will allow other developers to build completely decentralized cross-chain applications.

Cost & Efficiency

One of the main problems that Spectrum Layer 2 scaling solution solves is reducing the transaction (DeFi operation) cost and increasing the throughput of DeFi applications.

What are the main risks that could prevent you from delivering the project successfully and please explain how you will mitigate each risk?

Lack of dev forces

We're the part of the big Ergo and Cardano dev community. We will definitely find people who share our views and want to grow these 2 ecosystems.

Impractical consensus protocol

Roll-DPoS is used in a large IOT network with high churn and does well. We will partner with the company that successfully applied Roll-DPoS in their network to get some advice.

Lack of experience in Cardano development

We've built ErgoDEX protocol on Cardano using Plutus language. We can teach new developers in the team all the necessary technical tools for successful integration into the development process.

Please provide a detailed plan, including timeline and key milestones for delivering your proposal.

1st month

  • Networking protocol specification;
  • Generalized Blockchain Data format specification.

2nd month

  • Implement networking layer;
  • Spectrum.Network reference client architecture specification.

3rd month

  • Implement consensus layer.

4th month

  • Implement and run in the testnet a simple bridge based on early Spectrum.Network.

5th-6th month

  • Add Plutus/ErgoScript support;
  • Setup a testnet.

Please provide a detailed budget breakdown.

Lead Rust developer - 1 individual - $10,000/month

Senior Rust developer - 3 individuals - 3 * $8,000/month = $24,000/month

Senior Blockchain Researcher - 1 individual - $8,000/month

Senior QA engineer - 1 individual - $5,000/month

Tech manager - 1 individual - $5,000/month

-----------------------------------------------------------

Total per month: $52,000

ETA of the first testnet version: 6 months

Total funds requested: $312,000

Please provide details of the people who will work on the project.

ErgoDEX Founders

Ilya Oskin

Role: Co-CEO, CTO

Engineering Leader with 5 years of experience in the blockchain industry. Keen on functional programming. Took part in the development of the reference node of the eUTxO-based blockchain Ergo and its explorer. Designed and developed the first version of the ErgoDEX protocol from scratch.

Github: <https://github.com/oskin1>

Yasha Black

Role: Co-CEO, CPO

Product manager, UX developer, and JavaScript developer with 5 years of experience in the IT industry. Built a strong product team, and designed the first version of ErgoDEX user interface. Grew up ErgoDEX product to 15,000 active addresses (Ergo side). First touched crypto in 2019 as an investor.

LinkedIn: <https://www.linkedin.com/in/yasha-black-25852018a/#education>

--

Core team

Timofey Gusev

Role: Senior Core/Smart Contract developer

Github: <https://github.com/GusevTimofey>

LinkedIn: <https://www.linkedin.com/in/timofey-gusev-666446170/>

Developed smart contracts and execution bots for Ergo and Cardano sides of the ErgoDEX protocol (Scala, Haskell, Plutus). Designed and developed an internal Cardano explorer.

Alexander Romanovsky

Role: Senior Core/Smart Contract developer

Github: <https://github.com/Bromel777>

LinkedIn: https://www.linkedin.com/in/александр-романовский-10227a171/

Developed smart contracts, execution bots and off-chain services for Ergo and Cardano sides of the ErgoDEX protocol (Scala, Haskell, Plutus).

Ruslan Salakhov

Role: Frontend Lead developer

Github: <https://github.com/Ridel1e>

LinkedIn: <https://www.linkedin.com/in/ruslan-salakhov-9821ba142/>

Designed and developed the current version of ErgoDEX user interface. Has 7+ years of experience as a frontend developer and 5 years in building interface for financial tools.

Sergey Koshechkin

Role: Senior Frontend developer

Github: <https://github.com/FrankiePo>

LinkedIn: <https://www.linkedin.com/in/sergey-koshechkin-443738109/>

Developed the first version of ErgoDEX user interface

Gulnara Nigmatzyanova

Role: Senior QA engineer

6 years of experience in automation testing and dev process management.

If you are funded, will you return to Catalyst in a later round for further funding? Please explain why / why not.

As seen from previous experience, our team has a long-term vision of developing products and tools for Ergo and Cardano communities and the blockchain community in general. We will definitely return to Catalyst in the future to ask the community for funding. We see that the most challenging step after Spectrum.Network implementation is to build user-friendly applications (including mobile dApps) with a low churn rate and sustainable value for the end-user.

Please describe what you will measure to track your project's progress, and how will you measure these?

  1. [During testnet] Number of bugs and issues. These metrics should trend down after each completed sprint
  2. Monthly dynamics of network validators
  3. Monthly dynamics of dApps created on top of Spectrum.Netwrok

What does success for this project look like?

Achievement of the following goals can be considered a success for the project:

  • The network runs smoothly without security vulnerabilities and closes decentralized cross-chain needs for the global community;
  • Our team is able to develop and deliver high-performance cross-chain products on top of Spectrum.Network;
  • Third-party developers have an opportunity to develop from scratch or migrate their protocols on Spectrum.Network and make them cross-chain and high-performant.

Please provide information on whether this proposal is a continuation of a previously funded project in Catalyst or an entirely new one.

This proposal is a continuation of the previous one. More specifically, this proposal results from paragraph 8 of the previous detailed plan.

To date, 2 AMM protocols have been developed (Ergo and Cardano ones) and released to production (the Cardano side is in testnet). The next step is to link them into one protocol. We found that the most efficient way is Spectrum.Network.

See what has been done since the previous proposal:

cardano-dex-contracts: <https://github.com/ergolabs/cardano-dex-contracts>

cardano-dex-sdk-haskell: <https://github.com/ergolabs/cardano-dex-sdk-haskell>

cardano-dex-backend: <https://github.com/ergolabs/cardano-dex-backend>

cardano-dex-sdk-js: <https://github.com/ergolabs/cardano-dex-sdk-js>

cardano-explorer: <https://github.com/ergolabs/cardano-explorer-backend>

close

Playlist

  • EP2: epoch_length

    Authored by: Darlington Kofa

    3m 24s
    Darlington Kofa
  • EP1: 'd' parameter

    Authored by: Darlington Kofa

    4m 3s
    Darlington Kofa
  • EP3: key_deposit

    Authored by: Darlington Kofa

    3m 48s
    Darlington Kofa
  • EP4: epoch_no

    Authored by: Darlington Kofa

    2m 16s
    Darlington Kofa
  • EP5: max_block_size

    Authored by: Darlington Kofa

    3m 14s
    Darlington Kofa
  • EP6: pool_deposit

    Authored by: Darlington Kofa

    3m 19s
    Darlington Kofa
  • EP7: max_tx_size

    Authored by: Darlington Kofa

    4m 59s
    Darlington Kofa
0:00
/
~0:00