Today, blockchains are slow and costly because of scalability issues,

Scalability simply means the ability of a system achieve a higher TPS(transaction per second).

Thousands of dApps share a single blockchain. Imagine your activity on dApp A becomes so slow and too expensive because there are lots of activities going on on dApp B.

Skale takes a breakthrough approach towards scaling, using RANDOM ROTATION INCENTIVE SCALING. Random rotation incentive scaling leverages the security advantages offered by a large number of validator nodes by combining random node assignments to each chain along with frequent node rotation among the validator set.

With skale, each dApps run on its own ethereum blockchain for its storage, computation and other needs,without sharing resources with other dApps and with no gas fees.

Skale is an ethereum based network with no limited speed, capacity, and security.

SKALE Networks’s modular protocol is one of the first of its kind to allow developers to easily provision highly configurable blockchains, which provide the benefits of decentralization without compromising on computation, storage, or security.


Skale is a network of Elastic Sidechains run by independent validators located around the world. Validators run “Nodes”, which contain a number "Virtualized Subnodes", and can participate in multiple sidechains.

One SKALE Validator can run multiple Elastic Sidechains simultaneously, whereby the number of validators and capacity of each Elastic Sidechain is configurable by users of the system. Elastic Sidechains are created and managed through the SKALE Manager located on the Ethereum blockchain.

The SKALE Network is comprised of *SKALE Nodes and

*the SKALE Manager

Both located on ethereum mainnet.

Skale manager serves as entry point to all other smart contracts in the SKALE ecosystem. This contract manages the orchestration of all entities within the network, which include

*Elastic Sidechain creation / destruction

*Node creation / destruction,

*withdrawals, and



Elastic Sidechains provide all of the benefits of traditional sidechains alongside the security guarantees of truly decentralized networks.

When creating an elastic Sidechain, consumers select their chain’s configuration and submit payment to the
SKALE Manager for the duration of time that they wish to rent network resources required to maintain their Elastic Sidechain. To allow users to meet their business / budgetary requirements, they are provided with the option of selecting Elastic Sidechains starting with the minimum of 16 virtualized subnodes.

Each virtualized subnode is either using 1/128 (small), 1/16 (medium), or 1/1 (large) of each node’s resources. As the

network continues to evolve, it will eventually allow for users to specify the number of virtualized subnodes,number of signers, and size of the virtualized subnodes which will comprise their Elastic Sidechains.

All resources in the network are of equal value and the cost for consuming these networks is based on the size of the chain and the lifetime of the chain.As the network matures, the cost of network

resources will be calculated dynamically to account for current network conditions / system load.

After a creation request has been received by SKALE MANAGER, a new elastic Sidechain will be received and the end point will be returned to the creator.

When creating an elastic Sidechain, developers are provided with the option of “virtualized subnode shuffling” which is a security measure. Shuffling is encouraged to mitigate any collusion attempts by

virtualized subnodes within each Elastic Sidechain and is facilitated through the SKALE Manager in a similar fashion to the node exiting process.


Destruction occur when the consumer deposit for the network resources is finished or the consumer called for deletion of the elastic Sidechain.

Before the exhaustion of the rental deposit, the consumer will be notified about the pending deletion in order to give opportunity to add additional time to the chain’s life.

Once the rent is exhausted, the ELASTIC SIDECHAIN will be eligible for destruction through SKALE MANAGER. The destruction process will transfer any crypto assets from ethereum to their owners in the mainnet, remove all virtualized subnodes from there elastic Sidechain, hard reset their memory and storage and remove the Elastic Sidechain from the SKALE Manager before rewarding the submitter who commissioned the destruction of the chain.


Nodes form the infrastructure of a blockchain. All nodes on the blockchain are connected to each other and exchange the latest data with each other, therefore, all nodes stay up to date. They store, spread and preserve the blockchain data, so basically, a blockchain exists on nodes.

Before adding a node to the system,it needs to be verified by a prospective node which must run the SKALE daemon which will evaluate the prospective node to ensure that it is upholding network hardware requirements .

If the prospective node passes this verification step, the daemon will permit it to submit a request to join the network to the SKALE Manager. This request will contain both the required network deposit as well as node datas collected by the

daemon (e.g. IP address, port, public key,..). After the request has been committed to Ethereum, the prospective node will be added to the system as

*full node(all there resources will be utilized for a single elastic Sidechain)or

*fractional node(multiple elastic Sidechain).

After a node is created, it will have a large group of peer nodes in the network, randomly assigned to it. peers regularly audit node downtime and latency at predetermined periods (e.g. five minutes) and submit these

batched metrics to the SKALE Manager once for every network epoch where they are used to determine the node’s bounty reward.


When exiting the network, nodes must first declare their exit and wait a finalization period . After this
finalization period (e.g. two days), the node will be inactive and able to withdraw their initial stake from the network.
In the case that a user is unable to wait the finalization period and exits their node immediately from the network, it will be classified as a non-conforming (dead) node by SLA virtualized subnodes, and the bounty for the node will not be paid. It will be then scheduled to be cycled out of the chain.


At the end of each network epoch, the number of SKALE tokens minted for that period are divided equally amongst all nodes which were participating in the network prior to the epoch beginning. The number of these issued tokens which each node can claim are based upon the average of the metrics submitted by 16 of its 24 peers where the top and bottom four metrics are dropped to mitigate any sort of collusion or malicious intent by peer nodes. Any tokens which are not issued to nodes as a result of poor uptime / latency will be issued to the N.O.D.E. Foundation.


Subnodes within a skale node is known as skale virtualized subnodes.

Each Elastic Sidechain is comprised of a collective of randomly appointed virtualized subnodes which run the SKALE daemon and run SKALE consensus. Unlike other protocols, virtualized subnodes are not restricted to as one to one mapping between participating node in the network.

This is made possible through the containerized virtualized subnode architecture deployed on each node in the SKALE Network which allows
each node to run multiple Elastic Sidechains simultaneously. Each Virtualized Subnode participates in independent Elastic Sidechains.

This containerized architecture was selected as a means of bringing enterprise grade performance and optionality to decentralized application developers on par with centralized systems, which offer elasticity, configurability,

and modularity. Containers are divided into five main components that ship with a dockerized Linux OS allowing for each node to be hosted in a OS-agnostic manner. Each container is encapsulated within one of the following services.

  • Skale admin service
  • Node monitoring service
  • Virtualized subnodes monitoring service.

The SKALE Admin Service serves as the human interface for virtualized subnodes with the SKALE

Manager (located on the Ethereum Mainnet).

Functionality shipping with this interface includes the ability for

nodes to see which Elastic Sidechains they are participating in as well as the ability to deposit, withdraw, stake,

and claim SKALE tokens. Because virtualized subnodes within nodes are appointed randomly to participate in 9

Elastic Sidechains, there is no interface for being able to join or leave Elastic Sidechains within the network.

Node Monitoring Service is run on each SKALE Node and facilitates the performance tracking of each of that node’s peer nodes. Performance tracking is measured in both uptime and latency through a regular process which pings each peer node and logs these measurements to a local database.

Virtualized Subnode Orchestration Service orchestrates node computation and storage resources

to instantiate virtualized subnodes using a dynamically created virtualized subnode image consisting of

SKALE daemon,

*the Catchup Agent for syncing an Elastic Sidechain, and

* the transfer agent for

interchain messaging. This service also performs respawning of failed virtualized subnodes as well as

deallocation of resources to virtualized subnodes who have been decommissioned.


Security is one of the best things to be considered in a decentralized system, though it was said that 100% security cannot be attained. Because of this, architects mDe sure the amount of money and resources that will be needed to break the system is very high.

Since the SKALE architecture is based on Elastic Sidechains, a security compromise of SKALE could involve problem with a particular Elastic Sidechain. For example, a significant number of nodes could be affected by a computer virus due to a bug in the Linux kernel. In such a case, the default procedure is as follows:

  1. Elastic Sidechain owners suspecting a security compromise will issue a request to the Ethereum

    SKALE Manager contract to temporarily suspend the chain.
  2. The SKALE Manager will mark the Elastic Sidechain as suspended.
  3. Uncompromised virtualized subnodes will receive a notification from the SKALE Manager to freeze

    their operation.
  4. Clients of the Elastic Sidechain will be notified of the suspension and have their requests to the Elastic

    Sidechain rejected.
  5. The Elastic Sidechain creator will have an opportunity to consult with the N.O.D.E. Foundation

    Security Incident Response Team (SIRT) to resolve the issue.

After these, the respond will be to identify an uncompromised node and clone its Elastic Sidechain content to a new, uncompromised Elastic Sidechain. Once a new Elastic Sidechain has been established, the consensus

operation will be restarted and clients of the Elastic Sidechain will be notified. After the investigation is completed, SIRT will have the power to slash the security deposits of offending nodes.

SIRT(security incident response team) members are security members elected by skale stakeholders, once these members are selected, they are being compensated by N.O.D.E FOUNDATION.

Read more about Skale node: https://skale.network/docs/validators/skale-node


When a business or site is completely dependent on AWS i.e Amazon Web Services, their will be times when the business or sites fell offline. Even though preventive measures like load balancing are put in place to mitigate such happenings, but there’s actually nothing that could be done when the actual host provider goes down.

many scoff at the idea of providing uptime guarantees that exceed those of Amazon’s AWS, this is not a bold of a claim to those in the decentralized community. In fact, Bitcoin just hit 10 years of nonstop block production — something very few services as large can tout.people inside of the blockchain community know that this liveness comes at the cost of scalability. This is especially true of blockchains which use Proof of Work as a means by achieving consensus. So we see effort in the realm of developing more efficient concensus, SKALE is believed to be the best possible decentralized scaling solution for Ethereum’s 'Execution Layer’ by creating a consensus mechanism which can run over 20,000 TPS.

The process include


Network Security Assumptions

The protocol assumes that the network is asynchronous with eventual delivery guarantee, meaning that all virtualized subnodes are assumed to be connected by a reliable communications link, which can be slow, but will eventually deliver messages.

This model is similar to Bitcoin and Ethereum blockchains and reflects the state of modern Internet, where temporary network splits are normal, but eventually resolve. The delivery is achieved by sending virtualized subnode making multiple attempts with exponential backoff to transfer the message to the receiving virtualized subnode, until the transfer is successful.

Each virtualized subnode maintains pending transaction queue. The first virtualized subnode to receive a transaction will attempt to propagate it to its peer via outgoing message queues for each. To schedule a message for delivery to a particular peer, it is placed into the corresponding outgoing queue. Each of these outgoing queues is serviced by a separate thread, allowing messages to be delivered in parallel so that failure of a particular peer to accept messages will not affect receipt of messages by other peers.

After the completion of previous consensus round, each virtualized subnode TIP ID will increase by 1 and allow them to create a block proposal immediately.


To create a block proposal, a virtualized subnode will :

  • Examine the pending transaction queue to check if the total size of transaction in the pending queue e is less than or equal to MAX BLOCK SIZE
  • If the total transaction is less than or equal to MAX BLOCK SIZE,the virtualized subnode will fill in a block proposal by taking all transactions from the queue.
  • If the total transaction queue in the pending queue is more than that of MAX BLOCK SIZE,the virtualized subnode will fill in a block proposal of MAX Block SIZE by taking pending transactions from queue, by taking the oldest pending first before the newest.
  • The virtualized subnode will then assemble block proposals with transactions which are ordered by SHA-256 Merkle root from smallest value to largest value.
  • Incase the pending queue is empty, the virtualized subnode will wait for BEACON TIME and if the queue is still empty afterwards, the virtualized subnode make an empty block proposal with no transactions.


The data availability protocol guarantees that the message is transferred to the supermajority of virtualized subnodes. Once a virtualized subnode creates a block proposal it will communicate it to other virtualized subnodes using the following 5 step data availability protocol:

  1. The sending virtualized subnode A sends both the block proposal and the hashes of the transactions which compose the proposal B to all of its peers.
  2. Then each peer will reconstruct B from hashes by matching hashes to transactions in its pending queue. For transactions not found in the pending queue, the peer will send a request to the sending virtualized subnode A. The sending virtualized subnode A will then send the bodies of these transactions to the receiving virtualized subnode, allowing for the peer to reconstruct the block proposal and add the proposal to its proposal storage database.
  3. The peer then sends a receipt that contain a threshold signature share for B to A.
  4. A will wait until it collects signature shares from a supermajority (>⅔) of virtualized subnodes (including itself), A will then create a supermajority signature. This signature serves as a receipt that a supermajority of virtualized subnodes are in possession of B.
  5. Finally, A will then broadcast this supermajority signature to each of the other virtualized subnodes in the network.

After the steps above, a data availability receipt is required by all virtualized subnodes voting for proposal B whereby they must include supermajority signature in their vote; honest virtualized subnodes will ignore all votes that do not include the supermajority signature . This protocol guarantees data availability, meaning that any proposal B which wins consensus will be available to any honest virtualized subnodes.

The consensus uses an Asynchronous Binary Byzantine Agreement (ABBA) protocol. Skale currently use a variant of ABBA derived from Mostefaoui et al. Any other ABBA protocol P can be used, as long as it satisfies the following:

*Network model: B assumes asynchronous network messaging model described above.

*Byzantine nodes: B assumes less than one third of Byzantine nodes.

*Initial vote: B assumes that each node makes an initial vote yes(1) or no(0)

*Consensus vote: B terminates with a consensus vote of either yes or no, where if the consensus vote is yes, it is guaranteed that at least one honest node voted yes.


After the proposal phase complete, each A which has received supermajority signature for B will vote for ABBAs in a consensus round R.

The protocol is as follows :

  • For each R, virtualized subnodes will execute N instances of ABBA.
  • Each ABBA[i] corresponds to a vote on block proposal from the virtualized subnode i.
  • Each ABBA[i] completes with a consensus vote of yes or no.
  • Once all ABBA[i] complete, there is a vote vector v[i], which includes yes or no for each proposal.
  • If there is only one yes vote, the corresponding block proposal B is committed to the Elastic Sidechain.
  • If there are multiple yes votes, B is pseudorandomly picked from the yes-voted proposals using pseudorandom number R. The winning proposal index the remainder of division of R by N_WIN, where N_WIN is the total number of yes proposals.
  • The random number R is the sum of all ABBA COMMON_COINs.
  • In the rare case where all votes are no, an empty block is committed to the blockchain. The probability of an all-no vote is very small and decreases as N increases.

Once consensus completes with winning block proposal B on any virtualized subnode A, the virtualized subnode will execute the following algorithm to finalize the proposal :

  • Virtualized Subnode A will check if it has received the winning proposal B
  • If A has not received the proposal, it will request it from its peer virtualized subnodes for download.
  • A will then sign a signature share for B and send it to all other virtualized subnodes.
  • A will then wait to receive signature shares from a supermajority of virtualized subnodes, including itself.
  • Once A has received a supermajority of signature shares, it will combine them into a threshold signature.
  • A will then commit the B to the blockchain together with the threshold signature.

Read more about Skale consensus: https://skale.network/blog/skale-consensus/


The SKALE Network token ($SKL), is a hybrid use token which represents the right to work in the *network as a validator,

* stake as a delegator,

* access a share of its resources by deploying and renting an Elastic Sidechain or Elastic Blockchain for a period of time as a developer.

Skale was launched on Activate because founders believed Activate has done an incredibly thorough job of creating guidelines that will keep SKALE as compliant as is possible in the launch of the network and token offering. By having this, access was gained to the US markets, which is an incredibly important market for SKALE as many projects and dApps will be created in the US.

The final number of approved participants in the SKL token sale was 4,533 with $53,300,000 in purchase intent, which was more than ten times the total token availability. On Friday, September 11, 2020, the public token sale of SKL which powers the SKALE Network’s Ethereum scaling network, concluded. 3,736 people from 90 different countries purchased 167,139,884 SKL at $0.03 USD/SKL, creating a broad network of participants that spans the globe and significantly increases network security.

Purchasers must stake tokens into the network for a two month "proof of use" period. During the two month period the tokens will not be listed on exchanges nor will they be in a transferable state. After this period users are free to sell their tokens. After this, there will likely be an option to commit to a longer lock periods to gain higher staking rewards. SKALE made a concerted effort to align the interests of token purchasers with the core team and early supporters by creating long team and SAFT purchaser lockups.

$SKL serves as instrument for facilitating the following purposes :

  • Security of and staking in the network. SKL token holders (delegators) stake their SKL tokens to validators who run nodes that make the SKALE network function by validating blocks, executing smart contracts, and securing the network. They are rewarded with SKL tokens for their efforts.
  • Payment method for chain skale subscription fees. Developers uses skale token as a source of transaction for subscribing for access to elastic blockchain.
  • Serves as a reward to validators and delegators who stake their tokens. Rewards are accumulated from subscription fees made by developers
  • Governance and voting. SKL tokens are used for on-chain voting, which will control all economic parameters of the SKALE Network.


  • SKL was listed on Binance at 00:00 UTC December 1st with trading commencing at 1:00AM UTC December 1st. Opened trading for SKL/BTC, SKL/BUSD and SKL/USDT trading pairs.
  • SKL was listed on Huobi Global at 00:00 UTC December 1st with trading commencing as soon as deposit thresholds are met.
  • SKL was listed and ready for swapping on UniSwap via a community curated pool at 00:00 UTC December 1st. And number of other exchanges

SKL is an erc token, therefore, it is very easy for any exchange to list it.


  1. Number of tokens

*The Total supply of SKL tokens at Network launch is 4,140,000,000 *The Network has a Max

Supply of 7,000,000,000 tokens.

2. Distribution

*34.3% allocated to the Validator Community and Ecosystem

i. 33% of which is designed to be paid to validators via inflation at rates listed below.

ii. ~1.3% will go towards ecosystem community growth via grants and awards, and

payment for validator required ecosystem essentials for liquidity of the network token

*~25-28%% allocated to Network Supporters who purchase tokens prior to Network Launch

with the intent of running Validator Nodes, delegating, or using Elastic Sidechains for their

dApps. All are locked for periods of 6-36 months following network launch.

* ~7.7% are dedicated to support Protocol Development for future financing and grant efforts

to support operations and contracts that will improve, enhance, and support the Network.

* 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.

~16% to broader foundational team and~4% for Employee Token Option Pool to

ensure further development on the network.

*10% allocated to N.O.D.E. Foundation. 150 Million are minted at Genesis and 550 Million are minted at Month 6 with an unlocking schedule that commences at 24 months based on milestone achievements which include having an active running network and decentralized validator community running nodes.

*2.5% to the public token event

3. Vesting Schedule and Lock-ups

a. Pre-purchased tokens in prior SAFT rounds are locked from a period of 9 to 36 months

based on SAFT agreements. Lock period commences at network launch.

b. The team will be locked for one year and will have a 3-4 year vest. Lock and vest time period

commences at network launch.

c. The Foundation will vest over a 7 year period.

4. Inflation

a. Validator Rewards Mechanism: Validator rewards will mint in the first year at 9.3% of the

max supply of tokens. The validator rewards rate will ladder down for the first 6 years then

halve every 3 years to perpetuity until the max supply of tokens is reached in the network.

These numbers are subject to changes leading up to Mainnet launch based on economic

analysis and community fee.

$SKL is built on an innovative ERC-777 token standard which supports delegation on the token level. ERC-777 is fully backwards compatible with ERC-20, which means that it is supported by all participants of the Ethereum ecosystem with ERC-20 support.

Skale token address:https://etherscan.io/token/0x00c83aecc790e8a4453e5dd3b0b4b3680501a7a7

Skale token unlock schedule:https://supply.skale.network/supply/index.html

Uniswap skl-eth trading pool:https://info.uniswap.org/pair/0xf232d640a5700724748464ba8bd8bed21db609a6

Skale token contract :https://etherscan.io/token/0x00c83aecc790e8a4453e5dd3b0b4b3680501a7a7.

Learn more about Skale token:https://skale.network/token/



A mainnet is a blockchain that performs the functionality of transferring a digital currency from a sender to a recipient. Mainnet is simply the main network, whereby actual transactions take place on a distributed ledger.

Mainnet is the final product in blockchain projects that make it possible to send and receive digital currencies. Mainnets do undergo changes from time to time whenever project teams decide there is a need for updates or revision. More so, crypto based mainnet launches will have to include a wallet system. a mainnet is the main blockchain network for a project to run on after rounds of testing on the testnet. A TESTNET is a software that is identical to the software that is being used by a cryptocurrency. They are basically an alternative that is used primarily for testing purposes.

Mainnet is the real deal while testnet is just for experimental purpose.

A mainnet launch is a defining time for a blockchain project to open to public and begin mass adaptation. When a blockchain project team is ready to roll out their official end product, they will carry out a “mainnet launch”, putting the product into actual production and operations.

Skale Incentivized Testnet launched on May 20th and went smoothly with no downtime to ensure that SKALE’s mainnet is secure and maximally performant when staking becomes available on Activate.

Afterwards, a three mainnet phase was launched

Phase 1:June 30 2020

Phase 1 was a restricted Mainnet that have no bounty, transfers, or issuance active in the Network. This phase support the initial strengthening and security of the network, which was be further hardened and decentralized throughout Phase 2.

The network was restricted to validators who have run in the TestNet and have gone through an onboarding process. Due to resource limitations this list was capped in April, but will be opening up in Phase 3.

Phase 2: October 01 2020

Skale network phase 2 launch set stage to help ethereum recover from its burgeoning popularity and meet 1billion people over the coming years.

Skale network, a network built to help developers build Ethereum Dapps scale to more users with lower costs and better performance launched its phase 2 decentralized mainnet with over $80 Million USD in Total Value Locked. A global cohort of roughly 4,000 people and entities from 90 different countries are secured 135 SKALE Network nodes across 46 validator operators. This represents one of the most distributed decentralization efforts at the launch of a blockchain network to date and a successful model for token holders to earn rewards by backing network security pools.

Jack O’Holleran, CEO and Co founder of SKALE labs said “We are at the start of something very big from an industry perspective. It is amazing to see the SKALE Network become a part of this broader story with a truly decentralized and distributed network launch. Validators and delegators alike have real incentives to participate as SKALE’s economic model pools security in a similar manner to how DeFi projects pool liquidity. However, instead of being rewarded for providing liquidity pooling, token holders are rewarded because staking SKL delivers Proof of Stake security to SKALE Chains that will run Defi, gaming, and Web 3 applications.”

SKALE is built to support massive growth of the Ethereum blockchain, while providing developers with a full Solidity environment, and maintaining integrations and composability with the Ethereum ecosystem as a whole. By easing traffic and lowering transaction costs dramatically, developers can bring Dapps to market that live up to the high demands of consumers, thereby setting the stage for an exponential growth in Ethereum use.

The SKALE Network offers a sophisticated and effective approach to Proof of Stake – it uses a large pooled security model (pooled validation model) in conjunction with random node selection and frequent node rotation to enhance network security. Validators and delegators play a critical role in this approach, ensuring the SKALE Network is scalable, secure, and economically efficient. The SKALE Network also uses containerization and virtualization to turn a single server node into up to 128 virtualized subnodes. This unique network design increases the potential size of the node pool and opens opportunities for network delegators to participate in this growth.

Phase 3:December 01 2020

At this phase, unlock tokens can be transferred and exchanged. The only unlocked tokens at this phase will be tokens purchased in the Activate launch and tokens earned by staking or validating during the Proof of Use Period. All team and early supporter tokens are locked for a period of 6-36 months following the Phase 2 launch conducted on Activate.. This allows for a healthy start where speculation and volatility are pushed out to a point where the token utility, validator side growth, and dApp traction can take hold in a viable sustained manner.

Read more!!



As we all know, storing data on ethereum is now extremely expensive. For this reason, most developers don’t store as little as possible on ethereum.

A solution should be

  • Store some rich object in IPFS.
  • Get the IPFS hash of the object.
  • Store that IPFS hash on Ethereum.

Then the problem with storage should be solved,

Unfortunately, IPFS has not yet integrated its incentivization mechanism of storing data,your data may be deleted anytime.

So, businesses often run their own IPFS nodes and ‘Pin’ data to them to ensure that it won’t go away or trust a third party ‘Pinning Service’ but with that, it won’t be decentralized anymore.

This all said, IPFS isn’t the only solution - there are plenty of others that businesses / developers are integrating to address their storage needs. But why have a separate system for storage, altogether? It was with this mindset that SKALE embarked on making a cost-effective storage layer within Ethereum capable of handling files up to 100MB.

SKALE FileStorage consists of a few layers:

  • FileStorage.js
  • Filestorage.sol
  • Precompiled.cpp (skale EVM)
  • Node filesystem

FileStorage.js is a simple npm package that allows users to integrate SKALE FileStorage into their decentralized applications with just a few lines of code.

This package is an interface to Filestorage.sol which calls a precompiled smart contract (Precompiled.cpp) which has access to the node’s native filesystem. Each of these layers serves an integral part to the process of uploading, downloading, and deleting of files with the EVM.

Uploading a file

To upload a file, we call the uploadFile method with the following parameters:

{string} address - Your Ethereum address.

{string} fileName - The name of the file being uploaded.

{number} fileSize - The size of the file being uploaded.

{ArrayBuffer} fileBuffer - The data of your file converted into hex.

{boolean} [logs=false] - Logging flag.

{string} [privateKey] - Your private key (required for signing transactions

After ensuring that your fileBuffer is in the proper format, a transaction is then sent to FileStorage.sol to ensure that the specified account does not already have a file of that name. If this check passes, then Precompiled.cpp is called to verify that the file is less than 100MB and that if there is enough space on the node’s filesystem to free a contiguous block of memory in which to store the file.

If there isn’t enough space available, the caller will be informed and prompted to upgrade their Skale-Chain or delete some of the less useful files that are currently stored on their nodes. Otherwise, the space will be freed, the file will be updated to a status of UPLOADING, a FileInfo struct will be created in FileStorage.sol containing the name, size, and a boolean array indicating which chunks of a file have been uploaded.once all of that is done, the user will be charged (0.1eth/mb),then the file is broken into chunks of 1mb or less to start the uploading process. They are uploaded as separate transactions to FileStorage.sol. Because anyone can call the uploadChunk function, we check that the

  • status of the file is UPLOADING,
  • that the file belongs to the transaction sender, and
  • that each chunk is less than 1MB and
  • has not already been uploaded before proceeding

After all of these checks pass, the chunk will be uploaded to the node’s filesystem with Precompiled.cpp.

If chunk upload fails, the transaction will be retried before notifying the user that their data may be corrupt.

In the event that the chunk is uploaded, the index for that chunk in the boolean array will be set to true.

Then the finishUpload function will be called which verifies that the file is in an UPLOADING status and that all chunks have been uploaded before updating the status of the file to UPLOADED. FileStorage.js will then return the path of the uploaded file [ACCOUNT]/[FILENAME] as a string to the user. And that’s all about uploading.


We can do these in 2 ways

  • DownloadFileIntoBrowser: these will download into browser, these creates a write stream and writes the file in the computer.
  • DownloadFileIntoBuffer: downloads into buffer. Creates a writestream and writes the file into the buffer.

Both take the following processes

{string} storagePath - The path of the file in Filestorage.

{boolean} [logs=false] - Logging flag.

Before downloading a file, the first thing is to check the size using the getFileSize function, after this is done, the file is iterated over in 1MB chunks using readChunk which verifies that the corresponding file as well as the current chunk have been successfully stored on each node before reading it from storage and loading it into a Buffer which will either be returned to the user (in the case of downloading to a buffer) or written to a stream (in the case of downloading to the browser).


This is done by calling the deleleteFile method

{string} address - Your Ethereum address.

{string} fileName - The name of uploaded file.

{boolean} [logs=false] - Logging flag.

{string} [privateKey] - Your private key (required for signing transactions).

The process above execute the deleteFile method in FileStorage.sol which will verify that the file exists and is either in the UPLOADING or UPLOADED state. The file is then deleted from a node’s storage with the C++ remove function in Precompiled.cpp.

When the file has been successfully removed from each node’s filesystem, the file’s status will be updated to EMPTY and its respective FileInfo struct will be deleted from the smart contract.

"Scaling decentralized systems is at this point as much a user experience problem as it is a technology problem. At SKALE, we’re obsessed with creating a phenomenal user experience for the people out there actually building. SKALE Storage turns storage into a seamless experience for developers as they can leverage solidity and Ethereum Virtual Machine to store and call within the SKALE Chain," said Stan Kladko, SKALE CTO.

Skale was able to overcome the storage process by the use of elastic Sidechain.


“Two heads are better than one” they say. An ecosystem is good on its own but better with partners. When an ecosystem has strategic partners and more, it performs its functions even much more better.

A strong and comprehensive ecosystem is critical in a decentralized world and something that is not as easy to build and sustain as it might be in a centralized world. Having a rich set of partners is testimony to years of hardwork.

Skale integrates with major wallets and auth providers, data storage solutions, data explorers, oracles, validators, and blockchain API connectors, along with support for the most commonly used token standards and developer tools used by the Ethereum community. These supports made it possible to use skale to build and run dApps with near zero learning curve.


A validator is a participant in the network who locks up tokens in the network and runs validator nodes in order to help run the network. A Blockchain Validator is someone who is responsible for verifying transactions within a blockchain.

The SKALE Network is fortunate to have an extremely strong set of validators. SKALE had nearly 700 requests from validator teams all over the world.

SKALE’s validators have experience mining and validating for a number of Proof of Work (PoW) and Proof of Stake (PoS) networks including ETH2, Cosmos, Terra, Solana, Polkadot & Kusama, Near, Celo, and many more.

Skale validators did a very impressive job during the Testnet and in the launch of the SKALE Mainnet. With this, the SKALE core team gained incredibly confidence in the collective set’s ability to perform their duties to the highest degree to help expand the network, further the growth of affordable transactions, and bring about the decentralized revolution we have all been working so hard to achieve.

Some of the validators are:


01node has good qualities such as expertise, alignment, security and reliability.

01node has the expertise and time tested infrastructure to be a highly secure and reliable node operator on the SKALE Network. The existing validator nodes have secured value on several POS networks such as Cosmos, Iris, Terra, Kava, E-money, IOV, Solana, Secret Network, Chainlink and others who will soon launch like theGraph and Near Protocol.



Ankr is a validator and developer node support for 50+ blockchains, API support for 5 protocols and has a platform with ease of use.

The Ankr protocol marketplace allows easy access to an array of blockchains and provides users with the ability to deploy staking nodes as well as developer nodes in minutes.

Blog: https://medium.com/ankr-network


Audit.One has a fully centralized infrastructure and provide networks with greater geographical decentralization by running operations from India (Only major validators in this space working out of India).

AUDIT.one was started with the idea that the Validators of today will be the Auditors of tomorrow with access to real-time data and skin in the game, unlike the auditors of today. They have been running validators for various projects right from the very start of the Delegated Proof-of-Stake ecosystem (with Cosmos).



With the experience of running nodes for 20+ PoS networks, Blockdaemon has put in place 24/7 monitoring of machine and protocol metrics to avoid downtime-related slashing. Blockdaemon have Direct access to live customer support, knowledge-base and community resources. Blockdaemon is internally ISO 27001 compliant, with enterprise-grade security and backup systems and is used by leading exchanges, custodians, enterprises, financial institutions and 10k+ developers to connect commercial stakeholders to blockchains

Blog: https://blockdaemon.com/blog/

Blockware Solutions

Blockware is an Early investor in SKALE through Blockchain Opportunity Fund. They have been been working skale on testnet for a year. Blockware provides hardware procurement, mining rig colocation, professional mining, and staking pool operations

Blog https://t.me/joinchat/FHaaVBkKNrA1FCVMBveVlQ


Chainflow is a small and independent validator, run by Chris Remus (founder), he has has over 20+ years of experience designing and operating mission critical telecom, data center and IT infrastructure.he has been validating since he when he was working for Cosmos validator group since 2017.

Chainflow supports Supports decentralization by supporting a smaller, yet very capable and dedicated, validator operator. Also secure and has highly available infrastructure.

Blog: https://skaleblog.ghost.io/p/e9c2fbba-4fe4-4d3a-8989-64941a51559b/chainflow.io/tag/blog

Cypher core

Cypher core has the following advantages :

  • Consistency
  • Reliability
  • Resilience
  • Monitoring

Blog: https://medium.com/cypher-core

Dokia capital

Dokia capital is one of the best professional validators in blockchain space. They operate an enterprise-grade infrastructure, fit for institutional staking, and ensure the security and stability of the networks.



They have 30+ years of real world experience operating critical Internet infrastructure. They are Trusted by large institutional token holders from around the world and participate actively in network governance/community initiatives for protocols they support.

Their mission is to make it simple for token holders and developers to use, build and govern blockchains

Blog: https://figment.io/resources/


FreshSKALE team has been maintaining secure and stable servers since 1997, started investing in cryptoassets in 2013 and started operating validator services in 2018, with Tezos.



Trusted staking provider for industry leaders, including 40 of the top 50 crypto funds. Staked operates highly reliable and secure staking infrastructure for 30+ PoS protocols on behalf of the leading crypto asset investors in the industry.

Blog: https://blog.staked.us/blog


StakeWithUs the only staking infrastructure provider to be backed by a governmental entity (SGInnovate).

Stakewithus provides secured yield solutions for crypto asset investors. It was founded in February 2019 to meet growing demand across leading Proof-of-Stake protocols. It has since secured more than $30m USD in assets under its secure validation infrastructure for global clients, with over 15 projects across mainnets and testnets.

Blog: https://medium.com/stakewithus

Other validators are:

  • Stakin
  • WolfEdge capital
  • Anonstake
  • Chainode tech
  • Harshed×delight
  • Hashquark
  • Cerus.one
  • NGC(Neo Global Capital)
  • Bison trails

Read more on validators: https://www.google.com/amp/s/skaleblog.ghost.io/blog/validator-list-for-skale/amp/

Data explorers

The Graph



Decentralized storage

  • Arweave
  • Guer


  • Chainlink
  • Razor

Developer tools





Blockchain API connectors



With over 50 dApps are built on skale network.

Read more about Skale partners: https://www.google.com/amp/s/skaleblog.ghost.io/blog/skale-network-ecosystem-for-ethereum-scaling/amp/


Skale is the best platform for developers to build on, because it's provide speed, security and it's reliable, it's also provide each dApps built on it its own personal blockchain unlike other platforms.

Skale Website : https://skale.network/

Skale whitepaper:https://skale.network/whitepaper

Skale blog: https://skale.network/blog

Skale telegram: https://t.me/skaleofficial

Skale Twitter : https://twitter.com/SkaleNetwork?s=09

Thanks for reading!!




Crypto enthusiast, blockchain lover, article writer

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Crypto enthusiast, blockchain lover, article writer

More from Medium

Taking stock of 3 major trends in technology investment in 2022, meta-universe, cloud computing and…

The Complete Guide for Creating and Selling NFTs

DeFi Wizard Provides Smart DeFi Solutions to Polysports

How to Stay Sane During a Crypto Crash