Skale Crash Course
Preface
This guide is meant to be a go-to reference for anyone that would like to know more about the many features of one of the most innovative, full-fledged “Ethereum-as-a-service” platform that’s been developed so far (and which, at the time of this writing, is currently being improved upon day by day) which is the SKALE Network.
First, I will try to simplify some concepts, in an attempt to make them easier to digest and comprehend. Yet I believe (and you’ll almost certainly agree, especially upon reading this article) that the SKALE team has already taken care of doing the heavy lifting on most aspects, leaving only some technical breadcrumbs here and there to learn in order to make them our own.
We will examine 5 main aspects regarding SKALE Network features:
- We will provide some context, providing some non-exhaustive background information regarding SKALE Network’s History and about its founders
- Then we will define some concepts that I believe define SKALE’s essence and which pave the way to the subsequent chapters — I will take a dictionary-style approach in trying to define them but also giving some explanations.
- We will then go deeper into trying to answer the question “What is the SKALE Network?”
- We will then briefly touch upon the SKALE Token ($SKL), its use cases and distribution schedule.
- Finally, we will provide a logical sequitur to the token’s information off the previous chapter by following up with an $SKL Staking Guide
So, without further ado, let’s proceed and do so in an orderly fashion.
SKALE Network’s History
The SKALE Network was co-founded by industry veterans Stan Kladko and Jack O’Holleran in 2017.
- Mr. Kladko brought on the table 19+ years of experience in the fields of cryptography and IT infrastructures. He’s worked as a key research member of the JVM team (JVM standing for Java Virtual Machine) in the early 2000s and had a stint working with NSA and several other agencies. Not only that but also at the academic level, he boasts a Ph.D. in Physics (specializing in the Physics of Complex Systems) from the Max Planck Institute and has also been one of the top Ethereum Foundation contributors. Among his past working honors, he’s been through the Silicon Valley boom, by founding two most successful companies in the fields of cloud computing and data infrastructure (Cloudessa and Galactic Exchange, respectively — the former successfully acquired by Global Reach company.
- Jack O’Holleran is one hell of an entrepreneur, solid on core competencies in the fields of Artificial Intelligence, Machine Learning, as well as Blockchain & Security. After graduating with a Bachelor of Science from the University of Nebraska, he’s had many working experiences, among which we can name IncentAlign (a digital currency platform); Aktana, a machine learning project developed for the Life Science Industry; he’s also worked as an executive for Good Technology. This latest experience then culminated with Motorola’s acquisition of the company for circa 500 million USD, followed up by his onboarding as a Motorola executive. He’s been active in the crypto space since early 2013 when he then began working full-time in the crypto universe.
Stan and Jack met via common acquaintances while working at Signia Venture Partners and Floodgate and, just about after, they began looking for opportunities to partner and create their first company in the crypto universe.
Their main objective was to build DApps in a way that would not impede growth, allowing for scalability and creating a user-friendly experience that would allow manageable, yet uncapped growth. Stan contributed by bringing up ideas for the Architecture of the future network, defining and designing the processes that would allow apps to scale. Throughout the initial development phase with Jack, they came to realize the huge opportunities and big potential regarding the creation of an effective and efficient secondary layer solution that would build on top of Ethereum and that would streamline decentralized applications operations, allowing them to desirably, effortlessly, and cost-efficiently scale. The bottlenecks and inefficiencies that were haunting the future of existing blockchains were already quite apparent to them, making clear the point that a new scalability solution was desperately needed, especially with the continuously growing DeFi-related demand.
That could be officially considered SKALE’s inception and we could mark the day as of January 1rst 2018 on the calendar. The two founders officially bootstrapped the project, receiving seed in the blockchain/crypto space from companies such as the aforementioned Signia Ventures and Floodgate but also Winkelvoss Ventures, Multicoin Capital, Hashed, Hashkey, and, later on, many others.
More than three years have then passed since that fateful day — years filled with development and testing. SKALE announced the main-net plan and its subsequent phases. This included the launch of a public $SKL token sale, via the ConseSys Activate Platform. SKALE led the way as the first platform to utilize the Proof-of-Use consensus model on Activate, which involved the staking on the network (that is, the use) of purchased $SKL tokens by sale participants as proof of active use of the token, in order to permit the unlock, claimability and transferability of the tokens.
On June 30th, 2020, SKALE then launched the main-net’s first phase. The first version (limited on the functionalities as it did not support staking or token receiving/sending) was then followed by the token sale on ConsenSys Activate. This phase culminated in September with more than 4000 participants from over 85 countries joining the event.
The second phase of the main-net introduced delegation & staking support. More than 46 validator organizations were actively involved. Finally, main-net phase three occurred on December 1rst and coincided with the unlocking/release of the tokens that were delegated and staked in the Proof-of-Use period. Simultaneously, the $SKL tokens were listed on several illustrious centralized (Binance, Huobi) and decentralized (UniSwap) exchanges.
Some KEY Concepts to Understand
Before answering the big question “What is SKALE Network?” I’ve decided to borrow here two definitions and to explain some keywords, that deserve, in my humble opinion, a bit of probing before getting down to the details and inner workings.
The first “definition” that’s on the very first page of the SKALE Network’s PRIMER…
“The SKALE Network is a security and execution layer that connects with the Ethereum network and lets developers build their projects faster and with better performance. It is an elastic and decentralized blockchain network that supports thousands of independent blockchains, sidechains, storage chains, and other types of subchains — all tied to the Ethereum public mainnet […].”
…and a second, more concise that’s a snippet from the whitepaper
“The SKALE Network is a high-throughput, low-latency, configurable byzantine fault-tolerant, elastic blockchain network built interoperably with Ethereum[…]”
Inside both of these excerpts, there are some pregnant words, which bear somewhat denser meaning, for which I believed it would have been to unpack them — without using too much technicality for the explanations — to facilitate comprehension.
- Layer
First of all, SKALE Network is what’s known in the crypto world as a “Layer 2 solution”: we can consider it as a framework that’s built on top of another framework or existing protocol (that is, Ethereum in this case).
If you’re almost new to the crypto world you might be asking — why would anyone need to build a platform that’s constructed above another (already) working layer?
If instead, you’ve been around for a while, you would know perfectly what’s one of the main issues that Layer 2 solutions are trying to solve, with special concern regarding Ethereum: the current protocol can only process a small part of the actual demand/transactions. Higher demand leads to network congestion, which in turn determines higher fees and higher transaction time. That is, the network’s efficiency and effectiveness are suffering from delays and disruptions, which determine a real cost, and also a potentially detrimental user experience.
SKALE Network has been working up until today to present one solution to this long-standing, debated, concrete problem. The solution requires taking charge of a great part of Ethereum’s base layer throughput, improving speed, and reducing transaction fees to almost zero thus easing up the process immensely.
- SKALE as an *Execution* Layer
Now that we’ve got the meaning of the word “Layer”, the next small, yet significant step is related to understanding what does “Execution Layer” stand for…and that simply means that the biggest chunk of the processes and smart contract operations are executed on smaller side-chains, which are created ad hoc inside the SKALE Network, relieving the base network from much of the computations and, as written earlier, improving on several KPIs.
- SKALE as a *Security* Layer
Security refers here to the security architecture behind SKALE’s design. In order to ensure the integrity of the network and its nodes, SKALE Network is made of several side-chains — each of which can be thought of as an independent sub-network of computers (or nodes) on their own. The main threat to each side-chain is the risk of collusion between nodes, which could result in manipulation/distortion, with a potential threat posed by malicious actors being able to create forged transactions
SKALE’s network design utilizes a pooled validation model (Pooled Security) that prevents the security risk of node collusion by making sure that each SKALE chain is assigned nodes randomly and that those nodes are rotated with each epoch (a set period of time). This results in a high level of security, and also way better performance for blockchains applications.
- SKALE as an *Elastic* Blockchain Network
Elastic clearly conveys the meaning of a “material” that you can mold at will. Such is the nature of SKALE’s “Elastic” Sidechains. Developers are empowered, by being able to customize their chain configuration, in terms of bandwidth, computation/storage resources, pooled security options, and much more.
- SKALE as a Byzantine Fault Tolerant Network
Byzantine Fault Tolerant refers to a renowned IT “condition”/problem that’s present in almost any situation where consensus must be reached among computers (nodes) of a network and where there might be errors in the communication of that reached consensus.
The fancy word “Byzantine” inside the expression above owes its origin to the informal, “historical” description of the problem. Picture this situation with your mind’s eye: having received an order to attack an enemy army from the supreme commanding officer, three or more Byzantine generals must decide whether to actually conduct the attack or to retreat. Why? One (or even more than one) of the generals might be a traitor, plotting to deceive the others by communicating conflicting orders, thus weakening the chance of a well-orchestrated offense and putting each loyal general’s lives and their armies’ at risk — as well as jeopardizing the success of the attack.
Therefore, despite this seemingly pompous, yet now (hopefully) more logical expression, it’s easy to comprehend what this feature means in the case of SKALE Network: the SKALE team proactively addressed the security issue of potentially faulty/missing/incorrect communication among nodes in the Network (the generals of the previous story ) — and by design, there are several technical protocol implementations (ABBA) that guarantee “correct” consensus (if you’re curious about the “Asynchronous Binary Byzantine Agreement” or ABBA, you can read more about it here).
What is the SKALE Network?
Keeping in mind these key definitions, it’s important now to go deeper and get into the juices of the true use cases and inner workings of the SKALE Network.
So, we know that the main, underlying use case for SKALE’s Network is tied to its Elastic Sidechain’s Network, whose main aim, as stated previously, is to solve many actual issues tied to the Ethereum Blockchain.
We’ve briefly hinted at the fact that the Network’s Sidechains are made of Nodes. Actually, the nodes of which sidechains are comprised of are virtualized nodes, which at the same time, are created from actual nodes (computers) in the SKALE Network. Not only that but these virtualized nodes each have — reserved for themselves — a subset of each node’s processing power and memory resources. This design is aptly called “multitenancy”. So, you can now almost picture how the SKALE Network achieves its great flexibility via the configuration of each Sidechain: developers creating their own Sidechain will be able to customize both the chain’s size, as well as other features like the consensus mechanisms, the VMs, the parent blockchains, and various security options as well (e.g. subnodes shuffling frequency).
On a more comprehensive level, we could define the SKALE Network as a layer that’s composed of the permissionless SKALE Nodes that we’ve been writing of so far and also an “arbiter”, the SKALE Manager, which lives on the Ethereum Network.
We could imagine the SKALE Manager as Dante Alighieri’s “Charon” of the situation, as it serves as the entry point to all the smart contracts inside the SKALE ecosystem. But it also performs several other key functions, which we are listing below
The SKALE Manager is invoked whenever a Node is created/destroyed
In order to add a new node to the system, that same has to undergo an evaluation (which is run by another actor, the SKALE daemon), which, in turn, will verify that the node lives up to the expected hardware requirements.
If this verification phase succeeds, the daemon will send a “no impediment” message to proceed to join the network to the SKALE Manager. The message will contain all the necessary information and metadata, previously collected by the daemon (such as the deposit amount, the IP address and port, the public key, etc…). Finally, after the request will have been validated on the Ethereum network, the node will become either a fully-fledged <Full Node> or a <Fractional Node> — the only difference being that Full Nodes are committed to a single Elastic SideChain while Fractional Nodes are “multi tenants”, that is, they participate in sharing their resources over more SideChains to effectively implement Pooled Security. The Node Creation process completes with the assignment of a batch of “peer” nodes to the network. These will watch over the node’s performance (by measuring and collecting KPI data, such as uptime and latency), and this information will be used to determine the node’s rewards within each epoch.
At the same time, whenever a Node exits the network, it must first “declare” its intention to exit. After this has been done, a two days termination period follows suit, which is required to render the node completely inactive and to allow the withdrawal of the existing stake from the SKALE Network. Again, the SKALE Manager oversees this process and makes sure that the termination period is abided. In case this does not happen, the Node will be deemed non-conforming by the virtualized subnodes, resulting in the slashing of the node's rewards, then rejecting the node out of the sidechain, thus completing the Node’s “destruction” process.
The SKALE Manager is invoked whenever an Elastic Sidechain is created/destroyed
The creation of an Elastic Sidechain allows developers to configure the Sidechain itself. At the moment of the creation, a predetermined amount of $SKL tokens must be submitted to the SKALE Manager to accommodate for the required rental duration of the desired network’s resources (in the form of computation power and storage capacity).
Developers will be able to choose between several options that will meet their business requirements in terms of Elastic Sidechains sizing, starting with a minimum of 16 virtualized subnodes, where each subnode will be utilizing either
A. 1/128 (minimum sidechain configuration)
B. 1/16 (medium configuration)
C. or 1/1 (large configuration)
of each of the resources of the node.
Other configurable options are I. the number of subnodes, the number of signers, the virtualized subnodes shuffling (a security measure to prevent collusion attempts among virtualized subnodes in the sidechain) as well as the subnodes that the Sidechain will be composed of.
Then, in a process similar to the node’s creation, the Elastic Sidechain’s configuration information is then sent to the SKALE Manager, which will process the request and complete the creation of the Sidechain, returning its endpoint.
As opposed to an Elastic Sidechain creation, destruction occurs when the Network resources have been depleted or upon the confirmation of the creator’s destruction request. Again, the destruction process goes through the SKALE Manager and will result in the transfer of all the crypto resources from the Elastic Sidechain to Ethereum’s main-net, as well as the de-assignment of each of the Sidechain’s subnodes (making them available again for new, future Sidechains creation), wiping out the old storage/data in memory. Finally, the commissioner of the Sidechain’s destruction will be rewarded for freeing up space by completing its destruction process.
Elastic Sidechains are made of Virtualized Subnodes — Inner Workings
As explained previously, a subset of virtualized subnodes makes up an Elastic Sidechain. What we haven’t explained though are the inner workings of the network: the mechanisms that allow this protocol to work in a secure, efficient & effective manner.
It’s these virtualized subnodes that are involved in the creation of blocks, therefore allowing for the consensus mechanism to work efficiently in the background. A feature that’s uniquely ascribable to the SKALE protocol is tied to the fact that these subnodes are randomly assigned to each Elastic Sidechain — that is, the mapping of subnodes and nodes in the network is not assigned on a 1:1 ratio; instead each node can be sharing computational and storage resources belonging to different subnodes and, therefore, to different Sidechains. In this light, the word “Elastic” takes on even more meaningfulness.
Delving deeper — Virtualized Subnodes and “Containerization”
If we dug deeper, as if we were dealing with a babushka/matryoshka doll, we would eventually discover that Subnodes are, in turn, belonging to a containerized structure. The principle behind this architecture is offering modularity, flexibility, and empowerment.
Fundamentally, containers are, themselves, wrapped in within one of several services:
- the SKALE Admin Service → which is the go-to subnode’s UI that allows the interaction with the SKALE Manager. The interface is updated with real-time information regarding joined sidechains, as well as handling functions for token management.
- the Node Monitoring Service → which is active on each node of the Network. As the name suggests, its main function is to oversee peer nodes' performance and retrieve the corresponding information (in terms of uptime and latency) that has been assigned to the current monitoring node. This information is then collected, relayed, and averaged together — with other previously peer submitted metrics, throughout the epoch — to the SKALE Manager to determine the bounties earned by the nodes at the end of each epoch.
- last, but not least there’s the Virtualized Subnode Orchestration Service → whose denomination aptly gives a clear hint about its purpose: managing computation and memory resources as well as handling the SKALE Daemon, the Catchup Agent (which comes into play as a failproof “agent” in case of critical node events to aid catching up/resynching) and the Transfer Agent (which plays a role during inter-chain communication)
The Protocol Consensus Mechanism — Delegated Proof-of-Stake (DPoS)
This section wouldn’t be complete (and I’m not pretending exhaustiveness in anyways and in any case) without an attempt to explain the consensus algorithm on which the SKALE Network rests as its concrete foundation.
DPoS vs PoS
The concept of DPoS has been developed in 2013 by Daniel Larimer and represents a different “flavor” of Proof of Stake. The classic. PoS protects the network via an internal investment of the native token ($SKL in the case of SKALE network), making blockchain attacks potentially harder and more expensive to malicious attackers. DPoS, on the other hand, implement also a voting system where network stakeholders really “delegate” their work to a third party, so that they do will do the job of protecting the network. Also, the voting power in a DPoS-based protocol is proportional to the number of tokens owned by each user and the reputation of the delegates is influenced by the voting system, resulting in malicious delegates being slashed out or even replaced in case of ill-behaviors.
Delegated Proof-of-Stake inside the SKALE Network
DPoS has been employed by SKALE Labs to foster/favor *lawful* behaviors by noders. Each of the participants “invests” (that is, stakes) a predefined amount of $SKL in order to join and secure the network. As explained briefly above, actions that go against the rules of the network result in the slashing (punishment) of part of the vested $SKL tokens. On the other hand, nodes that abide by the requirements and keep up with the minimum uptime and latency, operational standards are rewarded with bounty tokens (whose amount is awarded at the end of each epoch and is metrics dependent).
SKALE Protocol’s Extensions — Storage and Inter-chain Communication
The SKALE Network boasts an enhanced File Storage system that allows the serialization of larger files compared to most current protocols in the space. Bigger block size (which translated as more data stored within each newly added block on the chain), direct access to each node’s storage thanks to a predisposed smart contract (which is also able to split and handle multiple, bigger file chunks, up to 1 MegaByte each) are what make the difference in terms of competitive advantages in this regard.
Inter-chain communication is made possible by Sidechains “group signatures”: put it simply, a Sidechain can “detect” whether a new block has been finally added to the chain queue. This event allows the activation and execution of smart contracts (e.g. to send or to receive crypto assets) on other Sidechains as well, therefore enabling inter-chain operability.
Skale Network Governance
During the initial phase of the SKALE Network’s launch, Governance power will be held by the N.O.D.E. Foundation, an entity that’s been created to aid and support the initial project’s take off. Transition to a Decentralized Governance model on the SKALE Network will occur gradually and empowering all token holders to vote onchain for their Network Representatives and the <ffoundation Council, through which stakeholders will be able to decide for the future of the protocol over key topics (security, key economic features, and progress), in accordance to the DPoS model outlined previously.
The voting system will be a simple “winner-takes-all” system, which — after a proposal has successfully been formalized and submitted for voting - will take into account all of the staking votes that participated in any voting round. Only users that have been staking $SKL for at least 90 days will be eligible to vote on the topics proposed by the SKALE Council. After the voting process — on any proposal - has been opened, voting will last for the next 14 days.
The SKALE Token — $SKL
The SKALE token ($SKL) is a utility and governance token, which fulfills several purposes:
- embodies the right to participate in the network as a validator
- allows users (Delegators) to stake — by delegating — in the network and earn rewards for staking.
- is used by Elastic SideChain creators as the primary means of payment for renting resources — for a predefined period of time — on SKALE Nodes/Subnodes (thus this way creating a new SideChain). It’s also awarded (to the commissioner) back whenever an existing SideChain gets completely commissioned for destruction.
- is also awarded to SKALE Validators for keeping up with Network’s standards in terms of latency and uptime at the end of each epoch.
Distribution of the $SKL token
The following information is “cast in stone”, and is fully drawn from the SKALE Network’s Whitepaper. Detailed and interactive information about the Token unlock schedule con also be read here.
The initial total supply of $SKL token at the genesis event was 4,140,000,000. The project’s maximum supply was hard-capped at 7,000,000,000 $SKLs.During the initial public token sale, 3500+ people coming from more than 90 countries from all over the world purchased more than 167,000,000 $SKL tokens at the price of $0.03 dollars per $SKL. After the starting Proof-of-Use period (that required buyers to stake for a 60 days period) the $SKL tokens finally hit the market.
The token distribution, according to the Whitepaper is then scheduled as follows:
Validator Community and Ecosystem tokens
34.3% of the total will be distributed to the Validator Community and the Ecosystem, of which
- 33% of which will be assigned to validators
- 1.3% will be granted and awarded to the community growth as well used to pay validators for providing network liquidity.
Network Early Supporters and Stakeholders
- 25–28%% given to early network supporters that purchased the $SKL tokens prior to the Network’s Launch event. These tokens have undergone locking periods of 6 to 36 months after network launch.
Protocol Development
- 7.7% of the tokens were allocated for protocol development and future budgetary/financing support to aid operations and potential partnerships that will in turn, support the SKALE Network and foster its growth.
Network Creators and Builders
- 20% allocated to Network Creators and Builders with a 3–4 year vesting period and 12-month lock both of which commence at Network launch date, putting total vest period at 5–6 years based on Q3 2019 Launch date. i. ~16% to the broader foundational team and ~4% for Employee Token Option Pool to ensure further development on the network.
N.O.D.E. Foundation
- 10% of the supply assigned to the N.O.D.E. Foundation, of which150,000,000 $SKLs were minted at Genesis and 550,000,000 $SKLs were minted at month 6, with unlocking starting after 24 months and dependent on the achievement of milestone KPIs (full-fledged, active network and the successful creation of a decentralized validator community).
Public Token Event
- 2.5% were assigned to the public token event.
Vesting Schedule and Lock-ups
- Tokens purchased prior to SAFT were locked from a 9 to a 36 months period, with locking starting at network launch.
- The team tokens will be locked for 1 year and will undergo a vesting period of ~ 4 years, with locking starting - again - at network launch.
- The N.O.D.E. Foundation vesting period will be 7 years.
Inflation and Validator Rewards
- Validator will be rewarded via inflation, at 9,3% interest of the total $SKL supply. Then rewards will decrease over the next 6 years, and later on, halving down every 3 years until the total supply of the $SKL tokens will be fully distributed. It’s important to note though that these parameters will be potentially subject to change due to future on-chain community analysis and voting.
One final trivia about $SKL is that it’s one among few tokens that employ the ERC-777 standard which embraces a larger and more comprehensive scheme and provides a marginal, yet an additional layer of security when it comes to transactions and is also backward compatible to ERC-20
SKL Staking Guide
After going deep into the mechanisms and technicality of the SKALE Network, we’re reaching now a “lighter”, maybe more palatable, and common topic. This section is meant to be an easy-to-follow (hopefully!) guide on how to do the staking of $SKL tokens on the Skale network, via the Consensys CodeFi Activate platform, using Metamask as Web3 Wallet (I will assume you’re already familiar with Metamask, if not good starting point is here)
Why Staking $SKL?
I’ve listed several reasons in the paragraphs above, going into details about the staking mechanisms. But since this is a dedicated paragraph, here I will produce a small recapitulation on the two points I’ve briefly and previously touched upon (in case you might have skipped through the above paragraphs):
- it helps secure the network
- yields reward to validators and delegators for providing liquidity and actively operating the network
- staked $SKL assets represent voting power — more $SKL staked means more power to vote and influence future governance decisions which, in turn, will influence the key economic parameters of the network
How to stake $SKL tokens on the Consensys Activate platform
**Before starting the process and reading through the guide below, please make sure that you have the $SKL tokens you want to stake in the wallet you want to use register on the ConsenSys platform as well as enough $ETH to cover the gas fees associated with the transaction.**
1rst Step — Create your first account
In order to get started, you need to sign up at the Consensys Activate website (link here), by clicking on the crimson-colored “Sign Up” button located on the top right corner of the page (in case you’re already signed up, you can simply access back by clicking on the “Login” button, right next to the “Sign Up” and fill in the credentials you’ve entered when you’ve first completed the account creation process)
After clicking, you will simply need to fill out the form with your details (in order country and state of residence, name, last name, your email), create a specific password, then check the blue inbox to indicate that you have read and that you agree to the Terms of use, then click on the blue button “Continue”.
Upon clicking on the “Continue” button, you should see a greetings-for-signing-up screen (sorry for the mouthful) that informs you that a confirmation email has been sent to the email address you’ve provided in the previous step of the process.
Check your inbox and look for the verification email from support@activate.codefi.network. If you don’t see it in your primary inbox, check the spam. folder. The email’s content should like the one below. Simply click on “Verify my email”.
You will be then redirected again to Activate’s login page. All you have to do now is enter the email and the password that you’ve utilized during the signup process.
The next screen you should see is a welcome screen, informing you that the SKALE Network’s token sale is closed to newly registered users but encouraging you to complete the registration in the case of future initiatives.
You will need to fill again your personal details, a process and a screen similar to what we’ve seen after clicking on the first sign up button.
Step 2 - Staking
After clicking on “Next” you will be redirected to your Dashboard. Click on “Staking” at the top of the page and then on “Connect Wallet” and then clicking on “Metamask” on the pop-up window that appears.
Scrolling down the page you will see a list of Validators and fees they collect for staking. If you’d like to learn more about the validators, you can click on any of their logos. This will open a corresponding validator window, with validator references and contact information, in case you’d want to ask for support. Choose the validator you wish, then click on the corresponding blue button “Stake”.
A new screen appears, explaining what comes next and you should read it through carefully. You will need to input the amount of $SKL tokens you wish to stake and the time period. Then finally you will review and confirm your request with your wallet. Click on “Stake. my first SKALE tokens” at the bottom right corner of the page.
Step 3 - Submit your Delegation Request
The staking dashboard will appear and you will have the chance to configure all the options related to your staking. Insert the amount of the SKL tokens you want to stake (to abide by Proof of Use, you will be required to stake at least 50% of your assets for 60 days at the least). Then, choose the staking period (also, please note that you need to stake more than 100 $SKL and that after staking your funds will be locked for the entire staking period). You can also check a recapitulation of the staking information you’ve inserted in the mid-top right corner of the page. Once you’re satisfied with your configuration, click on the blue checkbox (accepting the terms of Service), then on the button “Continue”.
Your stake will be activated at the beginning of the next epoch (which is the first day of each month) only once your delegation requested will be accepted by the validator you’ve chosen.
After you’ve clicked on the “Continue” button, a new pop-up window will appear, summarizing your delegation request. Read through the summary and when you’re ready, click on “Stake”.
Confirm the transaction on your wallet … et voilà! You’ve successfully staked $SKL tokens on the SKALE Network! Congratulations!!
Managing your Stake on the ConsenSys platform
Once you’re done staking, the provided dashboard will come in very handy to help you recapitulate all the information regarding your stake on the SKALE Network. The Activate UI will allow you to manage all of your active stakes, inside of the token inventory section of the Staking screen.
Inside the token inventory section, you will find a summary that explaining the composition of your assets. At the bottom part of the screen, you will also find an overview of the stakes. Again, be mindful that - as explained above - upon staking your $SKL tokens, the staking operation will effectively be activated only at the beginning of the next epoch and only if the validator of your choice accepts your delegation request. If this happens, this will lock your tokens for the whole duration of the staking period you’ve opted for at the completion of the staking process.
What are Epochs and how are Rewards distributed?
An epoch represented a predefined period of time within the SKALE network. During an epoch, nodes performance is assessed by peer nodes on parameters like latency and uptime.
Each epoch starts and ends on the first day of each month — thus an epoch equals one month of network activity. Both delegators and validators' $SKL rewards are paid out at the end of each epoch. These rewards are usually claimable several days after each epoch’s end date.
Again, in order to claim your $SKL rewards, you will need enough $ETH in your wallet to accommodate the gas fees required for the transaction. The good thing is that your rewards won’t disappear if you don’t claim them immediately and they have no expiration date.
To claim the $SKL rewards, simply navigate to the token inventory section, then click on “Claim SKL”. A new Metamask window will pop up and you will need to approve the transaction in order to proceed with the process.
One final cool configuration setting that you can toggle with is the “Auto-Renewal” option. It’s on by default and allows you to renew your staking period automatically (for the same duration as the one you’ve chosen previously) with the same delegator, thus re-delegating for you the tokens at the end of your staking period. Again, you can decide to toggle it on or off, and this will require to cover transaction fees.
Learn More about SKALE Netwoork
SKALE Network’s Website
For everything you need to know about SKALE Network, visit the official SKALE Network’s website.
SKALE Network’s Twitter
To keep up with the latest updates from SKALE Network, follow them on Twitter.
SKALE Network’s Telegram Channel
Join the conversation on Telegram Channel to stay up-to-date about SKALE Network.
SKALE Network on Discord
Get in touch and social with other members of the SKALE Network’s community. Join the Discord channel here.
