English news

SpaceSwap Shadow technology: One year anniversary of our in-house brainchild

SpaceSwap’s innovative Shadow technology was officially released 1 year ago. We introduced Shadow Staking as part of our Interstellar and Gravity pools

Shadow technology was initially designed and built to execute LP token staking in a very specific way. The tokens remain in the custody of the user at all times, which makes the staking process far more secure and transparent than the standard approach to staking. Since the tokens are staked without being sent anywhere, the whole process is almost gasless.

‌All you need to do is go to the official SpaceSwap website, choose the pool you wish to participate in, proceed to Uniswap or PancakeSwap, add your liquidity to the corresponding pool and then receive the LP tokens in your wallet. ‌Then, you just need to go back to SpaceSwap and activate the pool. No need to actually send your LP tokens to the SpaceSwap platform or pay for any extra transactions. The system automatically reads the information from your wallet, verifies your stake and you will start receiving your rewards.

Much has changed since that first release. Today, Shadow technology is a proven solution for many DeFi problems. We recently announced the Shadow Staking 2.0 version that was developed for integration into third-party projects. Shadow also entered the gaming world through the SIDUS HEROES metaverse. Below is a nostalgic look back at how it all started from the Lead Shadow technology developer…

History


The story behind the creation of Shadow technology began back in May 2018, long before the idea of ‘SpaceSwap’ even entered our minds. At the time, I was developing a product that was architecturally very complex and was attempting to link several blockchains together (including Ethereum, Bitcoin and many other networks). The challenge I faced was the creation of oracles and how to link them securely to the blockchains. I had intended these oracles to be fully available to users with completely open source codes. The main purpose of these oracles was to determine the security level of any given transaction. This was for the first draft of an architectural design for a large and very interesting application. And this is when asymmetric encryption (also known as Public-Key Cryptography) was first conceived as one possible solution.

A story about a little girl who inspired her dad

It was a warm spring day filled with the joy of family time. Right after breakfast, my young daughter called me to play Shopping Center with her and I could not resist. Holding some fake cash in my hand, I headed to the improvised shop located on two chairs in the middle of the room. The first thing I noticed on the counter was a self-propelled caterpillar robot that I had made a few years ago for one of my projects. The robot was badly damaged from my daughter’s child-like handling of it but it was still dear to my heart. I decided to purchase it and went to the cash register, which stood on the other chair at some distance from the counter. We haggled over the price for a while and then I paid for the remains of my craft. My daughter “signed” a random piece of paper, handed it to me and skipped over to the counter, expecting me to follow her with the “receipt”. This is when the penny dropped. Asymmetric encryption!


Asymmetric encryption includes some of the encryption methods that use public and private keys. This approach had two options: encryption of the actual data or a method to create an electronic signature. We were mostly interested in the second option. When a user, whoever or whatever they may be (even a program), owns a private key, they would be able to sign the data by obtaining a unique set of bytes for a unique set of data (messages) using a private key. For this idea to work, the encryption mathematics needed to be organized in such a way that it would be possible to check the correctness of the data using only the public key. If the public key did not correspond to the private key or if the data did not correspond to the signed data, then the validity of the signature would be questioned and the system would reject the signature and data.


The concept was accepted, although a month later for unrelated reasons, the project was canceled.

Two years on


Upon the release of the SpaceSwap project we were facing a new problem with the farming contract on the SpaceSwap platform. It was completely inflexible, incapable of customization and very expensive for the end-user. This greatly hindered our audience size and was unappealing to the average user. However, its functionality was crucial. It was therefore necessary to make it practically free for the end-user and flexible enough for management.

First of all, we studied the contract in detail. The first thing that caught our attention was that users were replenishing their deposits and so as a result, accruals were made. Everything was fine, but nothing happened with users’ deposits. They were not being used as liquidity for decentralized exchanges nor for any kind of loan contract. They just lay there idle and users could only use them to pay for gas. The gas was an obstacle to the withdrawal and deposit of funds. We therefore decided to completely refuse deposits. This increased safety several times over. What could be safer than keeping users' funds available to them with no need to pay for transactions? We came to the decision to use a Layer 2 solution and transfer all the calculations to our server, linking them to the contract.

But we still didn’t have a way to make accruals safe and cheap for the user. We needed a solution that would notify the contract of whom and what it should pay. And ideally, we wanted users to have the ability to request the reward themselves whenever they chose. The solution came quickly in fact, because we had already encountered a similar problem before — asymmetric encryption. So we started experimenting with contracts, trying to get them to verify signatures signed with a private key. Different types of encryption, different ways to organize the signed data. In the end, we found all the information we needed in Ethereum’s protocol documentation. This is how Shadow technology was born, allowing us to reduce the cost of our products for end-users and transfer all the functionality that could not be implemented using contract methods outside the contract. A week later, we began the ultimate testing of the new technology with the first farming service on Shadow.

Conceptually, the product is divided into 3 parts:

  • Smart contracts
  • Back-end
  • Front-end

Today, smart contracts and the back-end contain information about specially allocated back-end addresses that have the right to sign transactions — the signature function is only used when the harvest action is applied and the user withdraws their reward tokens. This system guarantees the reliability of the data regarding funds owed to the user, based on information relating to the availability, quantity and history of changes in the balance of tokens. The data referred to here only concerns LP tokens on the ERC-20 and BEP-20 standards, which the back-end constantly synchronizes with the contract and is where all the complex mathematical calculations are processed.


We conducted all the necessary tests and the testers reported the successful execution of every scenario and the absence of errors. We fixed multiple extra bugs and implemented numerous updates, every time making the product better. The product itself was heavily modified, acquiring new functionality such as the inclusion of a multiplier for staking, even for coins from other projects. The product was scaled on Binance Smart Chain and Avalanche.

All these fixes and changes have been taken over by the farming functionality itself, which has nothing to do with the concept of Shadow technology. The very foundation, the set of methods responsible for contract integration, the encryption and signatures – where these are concerned, not a single line has changed.

Future scaling


We have created an excellent piece of technology that links complex back-ends with contracts and enables users to perform actions themselves, while placing the execution of complex calculations where there is no cost to the user. And as for the issue of flexibility, the application of our Shadow technology is only limited by the scope of our imagination and our marketing plan. We naturally want to scale this convenient technology, primarily in two main areas.

Farming is in high demand right now and the demand comes not just from users, but from startup companies as well who are launching their projects in the cryptocurrency market. We are currently working on a project code-named Shadow 2.0. Not a single line of the Shadow technology’s code will be changed but its application will become larger as demand for this technology from users and partner companies starts to create a market for it. In fact, this is just one iteration and happens to be the next step in the transformation of our farming solution. We would like to improve it further and make it more diverse in terms of accruals and in terms of receiving information based on the calculations made. An additional case for using our technology is our tokens. Who knows what this will result in but there is still no special engineering solution for Layer 2, as opposed to the contracts that will be connected to our marketplace. The Farming Factory option allows our partners to set several incentivization systems for one pool, instructing the pool to give out one or more rewards in order to motivate users. Depending on how this is configured, our partners will be able to choose a strategy for calculating motivational bonuses. This strategy is formulated at the back-end. Based on data collected from the pools about users’ investments, the final value of bonuses can be calculated. Some of the Shadow Staking principles are now used on the SpaceSwap Starter platform. 

An interesting engineering solution is scaling to the gaming industry. The Shadow technology itself confirms data from a centralized source and this concerns not just the issuance of tokens, but in fact, everything.

This is the problem we faced while working on the architecture of the SIDUS HEROES game. In a complex game that uses a graphics engine, mechanics for real-time battles and other elements of gaming, there is a layer that calculates  players' behavior and their interaction with other players or obstacles — and this all implies transaction costs. A game that forces you to make a transaction for every little move made would certainly be expensive for the player. So we wanted to eliminate this.

We decided we would achieve this by using, conditionally, a three-tier architecture. Naturally, the first layer is the blockchain that stores the basic and most important information about the gameplay, the game hero and the game items. But the information about, for example, the presence of a wall and the collision of a hero's head against it — there is no point in storing this on the blockchain. We brought all this secondary information about the gameplay to the third layer. However, between these two layers, there should be a second layer that tells the other two layers what is right and what is not. Thus, together with the SIDUS development team, we have prepared a solution that uses our signature technology to enable integration and minimize the cost of the gameplay for the player.

With this approach, the user has the choice of when to save their game progress to the blockchain, when to receive an NFT card representing an item and when to simply enjoy the game itself without paying for gas. At the same time, the contract will ensure that all game information is completely reliable. This layer will allow us to scale our own SpaceSwap products for any game ecosystem feature, for instance token farming & staking, receiving additional rewards, marketplaces and much more. Let us know if you want to learn more about how Shadow technology has been implemented into SIDUS HEROES.

Shadow technology today and tomorrow


Today, Shadow is applied on three major blockchains: Ethereum, Binance Smart Chain and Avalanche, totalling 2281 users on all three networks. Even though it has been a year now, for us, this is only the beginning. We are or will be developing a cross-chain bridge based on Shadow technology and a marketplace that utilizes the solution. We are expanding our know-how with regards to different DeFi segments, covering even the most unexpected ones. We thank you all for your support and…

Stay tuned!

Website: https://spaceswap.app 
Telegram: t.me/SpaceSwap
Twitter: https://twitter.com/spaceswapdefi
Blog: https://blog.spaceswap.app
Discord: https://discord.com/invite/4hvxZNWGHP
YouTube: https://www.youtube.com/c/SpaceSwap