# Welcome to the Scala Wiki! Everything you need to know about Scala (and more). ## What is Scala? Scala is a secure, private, and mobile-friendly cryptocurrency linking IPFS and distributed technologies to build a globally scalable ecosystem. It provides an opaque blockchain, untraceable payments, unlinkable transactions, and blockchain-analysis resistance. Our vision is to distribute wealth for everyone and every device. We want to be the people’s coin. To achieve this goal, we focus on implementing solutions that are mobile-friendly and energy-efficient. There are about 4 billion mobile devices in the world, and we want to make sure that our ecosystem takes that into account. We also take a lot of time to improve the user experience so that our applications can be used easily by anyone. Obviously, our goal is also to bring useful utilities and to solve real-world problems, in a way that is economically viable for the project and to sustain our growth. We take advantage of next-gen technologies such as IPFS, WebTorrent and custom software to provide the utility of data storage and we use the proven CryptoNote protocol for providing the financial aspects. # History The history of Scala ## January 22, 2018 01:21:34 - Stellite genesis block was mined ## February 2018 #### Listing on Crex24 {% embed url="" %} crex24.com {% endembed %} ## March 2018 #### Listing on TradeOgre {% embed url="" %} TradeOgre (BTC-XLA) {% endembed %} {% embed url="" %} TradeOgre (LTC-XLA) {% endembed %} \ April 4, 2018 ------------- #### Stellite forked from the new V7 Cryptonight algorithm with some adjustments ## April 10, 2018 #### Listing on Coinmarketcap {% embed url="" %} coinmarketcap.com {% endembed %} \ May 4-5, 2018 ------------- #### First conference in Amsterdam at Chainges {% embed url="" %} Chainges Event {% endembed %} ## June 6, 2018 [Stellite v1.2.4.0 'Titanium v1'](https://github.com/scala-network/Scala/releases/tag/1.2.4.0) Titanium v1 Fork at block height: 194600. Highlights for V4 include: * Changed Proof-of-Work algorithm to our custom XTL variant 2 * An improved Difficulty Adjustment Algorithm (DAA) * A bump in minimum network fee and increased median blocksize limit With this release, we added a new `stellite-blockchain-downloader` tool. ## January 10, 2019 [Stellite v2.0.0.0 'Adamantium'](https://github.com/scala-network/Scala/releases/tag/2.0.0.0) Adamantium V2 Fork at block height: 503001. Highlights for V5 include: * A complete update to support the latest Monero features including Bulletproofs * A better transaction experience by consolidating outputs * Move from 1-minute blocks to 5-minute blocks * An update to our Proof-of-Work algorithm * Improvements to our Difficulty Adjustment Algorithm (DAA) ## March 22, 2019 Rebranding to **Torque** due to copyright issues with the name "Stellite". {% embed url="" %} ## August 13, 2019 [Scala v3.0.0.0 'V6 Himalaya'](https://github.com/scala-network/Scala/releases/tag/3.0.0.0) **Final rebranding to the official name: Scala** More information: **Himalaya V6 Fork at block height: 563810.** Highlights for V6 include: * New proof-of-work named DefyX. * A complete update to support the latest XMR features and bug fixes. * Changed emission curve and supply. ## March 12, 2020 The first release of the official Scala Mobile Miner, a high-performance and open-source application for mining Scala on Android mobile devices. Download here: Some highlights of this application are: * AMAYC machine-learning algorithm to protect the device * Temperature display * QR code feature to capture wallet address * Completely redesigned UI * Refactored framework * Payout widget * Live Pool statistics for pools based on nodejs-pool cryptonote-nodejs-pool frameworks ## July 31, 2020 Panthera V7 hard fork at block height: 662646. Highlights for V7 include: * LdPoW - A custom version of dPoW that will help against malicious attacks as well as help in increasing the sync speed of the daemon. * An overhaul of the Scala wallet which will help increase performance. * Updated DefyX to Panthera - the algorithm now includes Yespower instead of Yescrypt which helps both security and reliability. * Updated Scala with the latest XMR release containing bug fixes and new features. * Completely reworked economics and emissions to help further benefit the users of the platform. ## September 20, 2021 The first release of Scala Vault, a secure and lightweight wallet to store your Scala coins on any Android device. Download here: Some highlights of this application are: * Multiple Wallets * Subaddress Support * Stealth Mode * QR Code Scanning * Automatic price conversion to other currencies * Address Book * Easy-to-use UI ## February 17, 2021 The second major release of the official Scala Mobile Miner, a high-performance and open-source application for mining Scala on Android mobile devices. Download here: Some highlights of this release are: * Support for ARMv7 devices * Support for older Android SDKs * Revisited UI/UX * Mining Dashboard * Setup Wizard * New Payout Widget * Hashrate and Temperature charts * Updated statistics, balance and payouts * Get Support page * Better stability * Fixed minors bugs ## June 8, 2021 ![Scala Share](/files/-Mfn9WFWOlqq3tjbUFWS) The MVP release of Scala Share, a decentralized content delivery network built on IPFS. {% embed url="" %} Scala Share App {% endembed %} More information: ## October 28, 2021 The release of the Menger V8 specifications. More information: ## November 18, 2021 Creation of the Haku Labs Non-Profit Organization. More information: ## April 13, 2022 The start of the V8 Menger testnet and airdrop. More information: ## July 5, 2022 The release of Scallet, a simple browser-based wallet with everything you need to store XLA coins and manage transactions. {% embed url="" %} Scallet App {% endembed %} More information: ## November 2022 The first V8 Menger node operators elections. More information: ## September 30, 2023 The release of the Menger V8 mainnet.
More information: # Funding How we plan on funding the project After overcoming problems we had with our short 0.6% premine when we first started (Stellite), V7 will have officially addressed everything that we initially had set out to finish in our whitepaper and more. Unfortunately following this development, we quickly have run out of funds to continue forward. Luckily in the past, we were able to push on with the help of a handful of very dedicated and brilliant programmers and designers. But sadly it has been hard to keep up with everything, we’re struggling to pay for seemingly simple things like web servers, build servers, DNS charges, etc. This is disregarding the countless hours of work our team has put forward for the development of the project. We have tried donations and other schemes, but as soon as the first and second months are over, it inevitably dies out with no one to blame. We would also like to hire freelancers to help us bring more products onto the table (like a mobile wallet), but this is currently not possible for us. With all of this in mind, we have decided to set aside around 3 years' worth of PoW rewards for the development and progression of the project for the next 5 to 6 years, which is around 3.8B coins. The majority of these coins will be stored in cold storage with trusted nominees will be selected from the core team. The view keys of associated wallets will be given to the community to assess the movement of the coins. The coins will be allotted in such a way that incentivizes developers and the community to come up with new and bright ideas and to help implement the ones that we already have, such as a complete ground-up built mobile wallet and new applications that are built upon the Scala blockchain, like a network of storage devices. Any community member will be able to propose an idea and if there is support seen for the said idea they can be allocated funds for working on it with milestones. ## Premine We have put in place mechanisms for the community to verify the integrity of these funds. You can check the transactions from our premine wallet by using the following information. ### XLA #### Address SvkzckfVpUSWuSG4VS4WCL9KMTh39krgk6SLwVGLkZufh83ET8JjZ3yidaoURyHgLFDhFZEPPY12cHqYySVoV2x62XvMtJii5 #### View Key c021dfc635906dabe18a8a67872aac2e580eed5d5b19354755dfe7bd983c9a09 ### Other ways to help the project Scala is still a very small project, but with a passionate team behind it. Since we're so small the coin may not be listed on the biggest exchanges or even have enough volume to sustain our development/server costs/exchange listing fees with XLA alone. So we also have addresses that are given below that you can use to send donations to which will help the project. ### Monero 47vMLVhHsGNFPdbMADE7K5VqECsjdN4K5dH1trkkKZhKfyWdxjF5rpeWCgAUY9i7389tF8NCj42sCPMXwtuYgVqLSxXD5Wu ### Bitcoin bc1q2u9x0yrm8sthu509vn4k3gle627u2cg9aczacl ### Litecoin ltc1q62nr2xzxg55gntg075crjmdkecmhql7mgm4c9k ### Ethereum 0xe59e80a2f790defdAd80cb47a79c0141ae3Ea80a ### Solana 8a55ZdfH8pojGnHynXLsyWCXNfvrjRZKwM1HpqahN1ha # Roadmap High-level roadmap # 2021 High-level roadmap As you can see, many interesting things are coming up in 2021. Even if we have date targets to deliver these items, we have not added any timeline to this roadmap because we are evolving in such a complex environment that we prefer to focus on progress rather than the timeline. This being said, with the team in place we believe all of these items can be done before the end of 2021. We will also probably outsource some of the work to accelerate the development. ![Scala Roadmap](/files/-MapGj7QxcUWDT8AN6FK) # 2022 High-level roadmap More details here:
# 2023 High-level roadmap More details here:
# Network Condensed technical specifications of Scala Blockchain. | Spec | | | --------------------- | ---------------------------------------------- | | Pow Algorithm | Panthera (RandomX + yespower + KangarooTwelve) | | Max Supply | 21,000,000,000 with tail-emission | | Pre-mine | 3 years' worth of PoW rewards | | Block Rewards | (MoneySupply - A) >> 20 | | Decimal Places | 2 | | Difficulty adjustment | Every Block | | Block time | 120s | | Genesis Block | 2018-01-22 01:21:34 | | Ticker | XLA | # Features Feature descriptions of some of the major aspects of Scala The feature descriptions for all that is good about Scala will be under this category # Untraceable payments Describes how Cryptonote achieves untraceable payments. The ordinary digital signature (e.g. (EC)DSA, Schnorr, etc...) verification process involves the public key of the signer. It is a necessary condition, because the signature actually proves that the author possesses the corresponding secret key. But it is not always a sufficient condition. ![](/files/-LV5GZJvLIfmH0IE9XQY) Ring signature is a more sophisticated scheme, which in fact may demand several different public keys for verification. In the case of ring signature, we have a group of individuals, each with their own secret and public key. The statement proved by ring signatures is that the signer of a given message is a member of the group. The main distinction with the ordinary digital signature schemes is that the signer needs a single secret key, but a verifier cannot establish the exact identity of the signer. Therefore, if you encounter a ring signature with the public keys of Alice, Bob and Carol, you can only claim that one of these individuals was the signer but you will not be able to pinpoint him or her. ![](/files/-LV5Gc1_BrrLjHlGn8yH) This concept can be used to make digital transactions sent to the network untraceable by using the public keys of other members in the ring signature one will apply to the transaction. This approach proves that the creator of the transaction is eligible to spend the amount specified in the transaction but his identity will be indistinguishable from the users whose public keys he used in his ring signatures. It should be noted that foreign transactions do not restrict you from spending your own money. Your public key may appear in dozens of others’ ring signatures but only as a muddling factor (even if you already used the corresponding secret key for signing your own transaction). Moreover, if two users create ring signatures with the same set of public keys, the signatures will be different (unless they use the same private key). ![](/files/-M-SM2mvOHnQYOXSVPlM) # Unlinkable Transactions Describes how Scala achieves unlinkable transactions Normally, when you post your public address, anyone can check all your incoming transactions even if they are hidden behind a ring signature. To avoid linking you can create hundreds of keys and send them to your payers privately, but that deprives you of the convenience of having a single public address. ![](/files/-M-SO9wkJNrUxwiqc3DB) Scala’s CryptoNote solves this dilemma by an automatic creation of multiple unique one-time keys, derived from the single public key, for each p2p payment. The solution lies in a clever modification of the Diffie-Hellman exchange protocol. Originally it allows two parties to produce a common secret key derived from their public keys. In our version the sender uses the receiver’s public address and his own random data to compute a one-time key for the payment. The sender can produce only the public part of the key, whereas only the receiver can compute the private part; hence the receiver is the only one who can release the funds after the transaction is committed. He only needs to perform a single formula check on each transactions to establish if it belongs to him. This process involves his private key, therefore no third party can perform this check and discover the link between the one-time key generated by the sender and the receiver’s unique public address. An important part of our protocol is usage of random data by the sender. It always results in a different one-time key even if the sender and the receiver both remain the same for all transactions (that is why the key is called “onetime”). Moreover, even if they are both the same person, all the one-time keys will also be absolutely unique. ![](https://gblobscdn.gitbook.com/assets%2F-LV59Y28GtFOLyQ3_Vax%2F-M-SOGBFYztWGzGlrc97%2F-M-SPELa0GDjueBZnep0%2FScala%20Wiki%20Unklinkable%20Transactions%20Remake%202.png?alt=media\&token=20167e4f-10dd-42f2-baea-02e81e67906f) # Double-spending proof Describes how Scala defends itself against double-spending. Fully anonymous signatures would allow spending the same funds many times which, of course, is incompatible with any payment system’s principles. The problem can be fixed as follows. A ring signature is actually a class of crypto-algorithms with different features. The one Scala’s CryptoNote uses is the modified version of the “Traceable ring signature”. In fact we transformed traceability into linkability. This property restricts a signer’s anonymity as follows: if he creates more than one ring signature using the same private key (the set of foreign public keys is irrelevant), these signatures will be linked together which indicates a double-spending attempt. To support linkability, Scala's CryptoNote introduced a special marker being created by a user while signing, which we called a key image. It is the value of a cryptographic one-way function of the secret key, so in math terms it is actually an image of this key. One-wayness means that given only the key image it is impossible to recover the private key. On the other hand, it is computationally impossible to find a collision (two different private keys, which have the same image). Using any formula, except for the specified one, will result in an unverifiable signature. All things considered, the key image is unavoidable, unambiguous and yet an anonymous marker of the private key. ![](https://gblobscdn.gitbook.com/assets%2F-LV59Y28GtFOLyQ3_Vax%2F-LV5EKkEyBPy283f7Znv%2F-LV5H-FsVKTRxBB49SDk%2Fimage.png?alt=media\&token=d5e390d8-0605-4342-8070-ab8880563c90) All users keep the list of the used key images (compared with the history of all valid transactions it requires an insignificant amount of storage) and immediately reject any new ring signature with a duplicate key image. It will not identify the misbehaving user, but it does prevent any double-spending attempts, caused by malicious intentions or software errors. ![](https://gblobscdn.gitbook.com/assets%2F-LV59Y28GtFOLyQ3_Vax%2F-M-SPK6pc0oPyHg8JwD6%2F-M-SQGTFUxa0zXpnocFa%2FScala%20Wiki%20Double%20Spending%20Proof%20Remake.png?alt=media\&token=a51c453f-384f-4ae5-8ce2-10692a5999a0) # Blockchain analysis resistance Describes the resistance against blockchain analysis implemented in Scala There are many academic papers dedicated to the analysis of the Bitcoin’s blockchain. Their authors trace the money flow, identify the owners of coins, determine wallet balances and so on. The ability to make such analysis is due to the fact that all the transfers between addresses are transparent: every input in a transaction refers to a unique output. Moreover, users often re-use their old addresses, receiving and sending coins from them many times, which simplifies the analyst’s work. It happens unintentionally: if you have a public address (for example, for donations), you are sure to use this address in many inputs and transactions. Scala’s CryptoNote is designed to mitigate the risks associated with key re-usage and one-input-to-one-output tracing. Every address for a payment is a unique one-time key, derived from both the sender’s and the recipient’s data. It can appear twice with a probability of a 256-bit hash collision. As soon as you use a ring signature in your input, it entails the uncertainty: which output has just been spent? Trying to draw a graph with addresses in the vertices and transactions on the edges, one will get a tree: a graph without any cycles (because no key/address was used twice). Moreover, there are billions of possible graphs, since every ring signature produces ambiguity. Thus, you can’t be certain from which possible sender the transaction edge comes to the addressvertice. Depending on the size of the ring you will guess from “one out of two” to “one out of a thousand”. Every next transaction increases the entropy and creates additional obstacles for an analyst. ![](https://gblobscdn.gitbook.com/assets%2F-LV59Y28GtFOLyQ3_Vax%2F-LV5EKkEyBPy283f7Znv%2F-LV5H9tItvHK-8jX1XOc%2Fimage.png?alt=media\&token=445a5367-dc25-4fe8-ae14-676971461edd) # Standard CryptoNote transactions A brief introduction to standard CryptoNote transactions A standard Scala CryptoNote transaction is generated by the following sequence covered in the white paper. Bob decides to spend an output, which was sent to the one-time public key. He needs Extra (1), TxOutNumber (2), and his Account private key (3) to recover his one-time private key (4). When sending a transaction to Carol, Bob generates its Extra value by random (5). He uses Extra (6), TxOutNumber (7) and Carol’s Account public key (8) to get her Output public key (9). In the input Bob hides the link to his output among the foreign keys (10). To prevent double-spending he also packs the Key image, derived from his One-time private key (11). Finally, Bob signs the transaction, using his One-time private key (12), all the public keys (13) and Key Image (14). He appends the resulting Ring Signature to the end of the transaction (15). ![](https://gblobscdn.gitbook.com/assets%2F-LV59Y28GtFOLyQ3_Vax%2F-LV5EKkEyBPy283f7Znv%2F-LV5HGGL5Os01Ju4H9cB%2Fimage.png?alt=media\&token=2a80305c-45db-44de-824b-af1beab2cccf) # Zero confirmation transactions Description of Zero Confirmation transaction on the scala blockchain. One of Scala's main goals are to get adopted by the masses, to be used in everyday life for simple transactions. This is greatly hindered by the fact that transactions takes time to be added into blocks. We have made a custom point-of-sale system that works with our mobile wallets to allow transactions to go through to a merchant in less than a few seconds. The inner working of this function are very simple. When a transaction is broadcast onto the network, it first goes into a pool of transactions called the transaction pool or the memory pool, from here it is added onto a block, even with our block time being 120 seconds, it could take a couple of minutes more depending on amount of transactions in the pool. To avoid this waiting period we are allowing merchants to accept 0 confirmation transactions. The point of sale will also come with an option where the merchant can set the amount of confirmation needed, for instance if the transaction is of high value. Another solution we provide to the users is to use a semi-custodial application called ScalaPay which uses a centralized database of transaction to be handled in a similar fashion of how traditional exchanges handle them, which is by using a simple pool of transactions on a single server before doing a commit onto the network, this is mostly for the novice users for whom setting up a regular node or a node which connects to a remote node is not feasible. Thus increasing even more the adoption capabilities. # Adaptive Limits Describes the adaptive parameters of the Scala Blockchain A decentralized payment system must not depend on a single person’s decisions, even if this person is a core developer. Hard constants and magic numbers in the code deter the system’s evolution and therefore should be eliminated (or at least be cut down to the minimum). Every crucial limit (like max block size or min fee amount) should be re-calculated based on the system’s previous state. Therefore, it always changes adaptively and independently, allowing the network to develop on it’s own. Scala’s CryptoNote has the following parameters which adjust automatically for each new block: * **Difficulty** The general idea of our algorithm is to sum all the work that nodes have performed during the last 720 blocks and divide it by the time they have spent to accomplish it. The measure of the work is the corresponding difficulty value for each of the blocks. The time is calculated as follows: sort all the 720 timestamps and cut-off 20% of the outliers. The range of the rest 600 values is the time which was spent for 80% of the corresponding blocks * **Max block size** Let MN be the median value of the last N blocks sizes. Then the “hard-limit” for the size of accepting blocks is 2\*MN. It averts blockchain bloating but still allows the limit to slowly grow with the time if necessary. Transaction size does not need to be limited explicitly. It is bounded by the size of the block. # Panthera PoW algorithm Describes the proof-of-work (PoW) algorithm used in the blockchain. ## (RandomX + Yespower + KangarooTwelve) = Panthera ![](/files/-MKjXzsaMdcwHqjWkUGP) Scala uses an algorithm technology combining [RandomX](https://github.com/tevador/RandomX) with our own variant of [yespower](https://www.openwall.com/yespower/)*.* In addition we have combined a quantum resistant algorithm called [KangarooTwelve](https://keccak.team/kangarootwelve.html) to create a new PoW algorithm that we called *Panthera*. It is faster than RandomX and is extremely resistant to not just *ASICs* and *FPGAs,* but is also rated level 2 quantum-resistant due to the inclusion of K12. ## Technical details *RandomX* utilizes a virtual machine that executes programs in a special instruction set that consists of integer math, floating point math and branches. These programs can be translated into the CPU’s native machine code on the fly. At the end, the outputs of the executed programs are consolidated into a 256-bit result, using a cryptographic hashing function (*Blake2b*). In **Panthera**, the [Blake2b](https://en.wikipedia.org/wiki/BLAKE_\(hash_function\)) hash is further hashed using Yescrypt-RH and KangarooTwelve, which makes it much more difficult for GPUs to attain an unfair advantage, and which also allows the algorithm to be resistant to ASICs/FPGAs and level 2 quantum computers. # Diardi Description of our semi-decentralized checkpointing mechanism Diardi is loosely based on the technology of dPoW created by Komodo (KMD), but the code is completely rewritten by the Scala Team. Essentially with dPoW, you checkpoint the daemons blocks onto another stronger chain (like Bitcoin). However, we didn’t want to “bloat” Bitcoin because we all in the team love Bitcoin and thought that dPoW was just too pollutive towards other networks. We then agreed that the idea of locking a lock with another lock is not the smartest idea, because if one lock becomes weaker than the other, it can create new vulnerabilities. Deriving from the ideas of dPoW we figured we could probably adapt it to our needs, This was the starting point of Diardi v1. So we got to work on our own version of dPoW which doesn’t use any other blockchain. Instead, our version used a blockchain that was distributed among prominent members of the community that stored checkpoints ## **Diardi v1** Every hard fork from the beginning the community will democratically elect 16 members from the community to run and maintain these nodes. Node operators are not required to own a single coin of Scala to run these nodes but should have expertise in the management of servers, and also a basic knowledge of blockchain technology. In addition, because these nodes are able to be publically monitored, if they try to “cheat” in any way, their action is open to public acknowledgment, essentially undermining the validity of their own well being. And for the services provided by the maintainers of these light dPoW nodes, they will receive 90 blocks worth of rewards daily. ## **Diardi v2** Diardiv1 was mainly something that was not tied with consensus, maintenance and checking was difficult for nodes and it was something that was ephemeral, we wanted to change that with v2. Diardiv2 is based on a system that incorporates a completely different proof-of-work along side our main PoW Panthera. Each Diardiv2 node maintainer will have a specific wallet with it's very own spend and view key with which they can mine every 4th block in the network. No same wallet owner can mine 2 consecutive Diardi blocks, they're also rewarded 1/4th of the block reward for providing their service. ## Proof-of-work and Difficulty of Diardiv2 Blocks Felidae is the proof-of-work that the diardi maintainers will use for mining their blocks. It's orders of magnitude faster than Panthera and it was designed to be that way. Like Panthera it is also CPU friendly and is also quantum computing resistant. Felidae uses KangarooTwelve(SHA-3) and Blake3 in tandem to generate a unique hash, Blake3 is touted as the fastest algorithm to date and K12 is rated to be level 2 quantum resistant. The difficulty algorithm that we use for both diardi and regular blocks are the same, since Felidae algorithm is orders of magnitude faster, it will adjust as required. ## Diardiv2 Election Diardiv1 as our community was much smaller we were able to pick out prominent members and give them the ability to checkpoint blocks, this was not democratized as we initially intended and we wanted a better way to do things from the get go. For v2 we're doing things very differently. We believe that the major stakeholders of the project should have the most say in how the chain is being secured. Hence anyone who holds XLA will be able to redeem vXLA (vote XLA tokens) which are 1:1 in parity with XLA on a forked chain will be able to use those tokens to stake for themselves or pool tokens with other users and stake that way. The accounts with the most coins staked during a given period will be given the opportunity to mine Diardi blocks. Anyone holding XLA can be a part of this process. The team decides how many operators get to be on the list for instance the minimum number of people elected would be 32 and the maximum would be 128. Everything depends on the number of people that participates. # Wallet The wallet applications that you can use to store and spend Scala There are mainly 4 different methods you can use to store and spend Scala. * GUI Wallet * This option is available for Windows, Mac and Linux operating systems. * CLI Wallet * This option is available for Windows, Mac and Linux operating systems * Scala Vault * This option is available for Android * ScalaPay * This options is available for all platforms with a web browser and also available on Android/iOS as native apps. # GUI Wallet A guide on how to use the GUI wallet. This document will tell you exactly how to set up and operate the Scala GUI wallet. The latest version of the wallet can be downloaded [here](https://github.com/scala-network/scala-electron-gui/releases). > **Mac and Linux users skip to Step 1.** ### **Windows** #### Install Electron **W**allet and allow Defender permissions. When installing the wallet the Windows Defender Smart Screen will prevent you from opening it unless you give the file permission. Click `Run anyway` to give the executable permission. Now run through the installation prompts and then click install. ![](/files/-MHJ7ftT7c6xHAb8-LIU) Once the installation has finalised open the Scala Wallet by clicking your "Windows" key or the start menu and searching for`scala electron wallet`. ## **1: Running the wallet for the first time** On windows, once the installation has finished, open the Scala Wallet by clicking your "Windows" key or the start menu and searching for `scala electron wallet`. ## **1: Running the wallet for the first time** #### 1.1: Choose your preferred language ![](/files/-MHJAaSGDIuNPWCLJNw0) #### 1.2: Configure your settings Default settings are fine to use. > This is not required but if you would like to run your own node and broadcast your own transactions check the `Local + Remote Daemon` or the `Local Daemon Only` option. ![](/files/-MHJBbDovsuTHon5RGKr) ### 2: Creating/importing Wallet. To create a new wallet click the `Create new wallet` button. Next fill in the input fields that are required. It is recommended but not required, however you should consider encrypting your key with an optional password. Once input boxes are filled in click `CREATE WALLET` button. ![](/files/-MHJDCMkkYMohPA7iKov) #### 2.1: Importing Wallet from seed. \ To import a wallet from seed click the `Restore wallet from seed` button. Next fill in the following input fields: * Wallet Name: Enter a name for your wallet. * Mnemonic Seed: Enter the seed phrase that was generated when intially creating your wallet. * Restore from Date: If you know the date at which the wallet was created, enter the date or block height. > It is quicker to restore from the date in which you generated the wallet. * Password: Enter an optional password. * Confirm Password: Enter the same password to confirm spelling. Once input boxes are filled in click `RESTORE WALLET` button. ![](/files/-MHJDrTTUJ7pCtzMEpDg) # CLI Wallet A guide on how to use the CLI Wallet # Scala Vault A Guide on how to use the Android Scala Vault # ScalaPay A guide on how to use ScalaPay. Currently on maintenance. # Mining DefyX: Proof-of-Work Algorithm. DefyX allows computers to contribute in a Proof-of-Work (PoW) mining system, where computer processing power bands together to solve hashes in the Scala blockchain. To use our command-line miner, you can download the file on Scala's' Github found [here.](https://github.com/scala-network/XLArig/releases) For any questions about the installation and use of the miner, please visit the FAQ page in the Scala Wiki. ![](/files/-M-OGnKHtvn8oiFm7Ko9) # Mobile Mining A Mobile Mining Application for the Scala Network. ## Mobile Miner The Mobile miner is an application able to solve low diff blocks given by any pool server that supports it. For now, the application is only available for Android devices, because Apple limits the implementation and distribution of cryptocurrency and mining applications. The maximum temperature the device can reach when mining will be set using a deep learning program within the app called AMYAC, whose purpose is to locate a mobile phone's maximum and safe operating temperature (although most devices can get warmer). When the CPU reaches that limit, the miner turns itself off until the phone gets back to normal temperatures and then begins once the device is back to the 0 potential range. This way we can ensure the device never gets so warm that the lithium ion battery suffers any damage. ![Scala Mobile Miner](/files/-M2VjyZWjhJKS4wiAijx) ## AMYAC protocol The AMAYC (As-much-as-you-can) protocol that we developed uses deep learning to find devices optimal settings, allowing to mine without damaging hardware while easing power consumption. Benchmarking is done on the client side in the first few mining CPU cycles which takes around 8.6 seconds on a mid tier smartphone. It makes use of a pre trained neural network to give an efficiency rating used by the miner to calibrate later on. The dataset training the network is a culmination of data from hundreds of devices, providing us with a clear cut idea of how good it can perform without damaging itself. Below given is a sample set of data which is used to train the neural network. ![AMYAC protocol](/files/-M-NFhm7nRUQeT0R8bLr) ## Neural Network implementation for AMYAC protocol Traditional benchmarking techniques do not fit well to the mobile devices use cases. They are too slow, computationally intensive and usually do not take the device temperature in account. With the neural network we will be able to find the standard in a very short span of time and also resource efficiently. For the implementation we will be using a simple classifier. We have made a custom node module for tests, the usage is very simple as shown below, the code for this module will be opensourced along with the miner. ![](/files/-LV5GPY5X_-o59HrnR54) From the above code it shows that the hash rate of 5H/s at 35 degree celsius is somewhat okay clocking in at 50% rating. From this we can truly understand the potential of this benchmarking approach. # Bridge Wrapping XLA and unwrapping wXLA ## Scala Network Bridge Guide The Scala Network Bridge facilitates seamless, bidirectional asset transfers between the native **Scala Network** and three major ecosystems: **Solana (SOL)**, **Ethereum (ETH)**, and **Binance Smart Chain (BSC)**. This process allows users to **wrap** native **XLA** into **wXLA** (Wrapped XLA) for use on external chains, and **unwrap** wXLA back to native XLA on the Scala Network.
### What is a Bridge and Why Do You Need It? Imagine the world of cryptocurrency as a collection of separate islands. Each island (like **Ethereum**, **Solana**, or **BNB Chain**) has its own unique rules, currency, and shops (apps). Normally, you cannot take your money from one island and spend it on another; you are stuck where you started. A **crypto bridge** acts as a secure ferry or tunnel connecting these islands. It allows you to move your value from one network to another without selling your assets or using a centralized bank. #### How It Works (The "Locked Box" Concept) When you use a bridge to move assets (like **XLA**) from the **Scala Network** to another chain (like **Ethereum**): 1. **Lock**: The bridge takes your native **XLA** and locks it in a secure digital vault on the Scala Network. 2. **Mint**: Once the lock is confirmed, the bridge creates an equal amount of **Wrapped XLA (wXLA)** on the destination chain. 3. **Result**: You now have **wXLA** on Ethereum that behaves exactly like a native Ethereum token, even though the original **XLA** is safely sitting on Scala. The value remains **1:1**. When you want to go back, you "burn" (destroy) the **wXLA**, and the bridge unlocks your original **XLA** on the Scala Network. #### Unlocking DEXs and dApps The primary reason to use a bridge is to access **Decentralized Exchanges (DEXs)** and other **Decentralized Applications (dApps)** that don't exist on your home network. * **Access New Markets**: Suppose a popular trading platform or a high-yield savings protocol only exists on **Ethereum**. Without a bridge, your **XLA** on Scala is useless there. By bridging to **wXLA**, you can instantly trade, lend, or earn interest on that Ethereum platform. * **One Wallet, Many Worlds**: You don't need to create new accounts. Your single wallet address works across these connected networks. The bridge simply allows your assets to "travel" to where the best opportunities are. In short, bridges turn isolated islands into a connected global economy, letting you use your XLA anywhere in the crypto world. # Wrap XLA ### How to Wrap XLA (Scala → ETH/BSC/SOL) Use this sequence to move native **XLA** from the Scala Network to an external chain, where it becomes **wXLA**. 1. **Connect EVM Wallet**: * Navigate to * Connect your **MetaMask, Phantom** or other EVM wallet. Ensure it is currently set to the **Scala Network** (or the source network holding your XLA). 2. **Configure Transfer**: * **Select Source**: Ensure the source is set to **Scala Network**. * **Select Target Chain**: Choose your destination ecosystem (**Ethereum**, **BSC**, or **Solana**). * **Enter Amount**: Input the amount of **XLA** you wish to wrap. * **Enter Destination Address**: Paste the address of your **Target Chain** wallet. * *For ETH/BSC*: Paste your MetaMask address (same address works for both if using the same seed). * *For SOL*: Paste your **Phantom** wallet address. 3. **Submit Swap**: * Click **Submit Swap** (or **Bridge**). * MetaMask will prompt you to sign two transactions: 1. **Approve**: Grant the bridge contract permission to access your XLA. 2. **Confirm Transfer**: Lock your XLA on the Scala Network. 4. **Transfer Completion**: * The bridge will automatically lock your XLA and mint the equivalent **wXLA** on the target chain. * Wait for the confirmation time (typically 5–15 minutes). The funds will arrive at the **destination address** you specified. * *Note*: On ETH/BSC, you may need to manually import the **wXLA token contract address** in MetaMask to see the balance. 5. Contract addresses: * ETH contract address: 0xBE13CfedCdF6A3Dbd847fDAabb67A21b24EFE3bB * BSC contract address: 0xBE13CfedCdF6A3Dbd847fDAabb67A21b24EFE3bB * SOL contract address: FVt4Q4X9qUxZaArVTT7b62tuiuV9hFGhZG12Bsi2vqFD\
# Unwrap XLA ### How to Unwrap wXLA (ETH/BSC/SOL → Scala) Use this sequence to return **wXLA** from an external chain back to the native **Scala Network** as **XLA**. 1. **Connect EVM Wallet**: * Navigate to * Connect your **MetaMask** wallet (for ETH/BSC) or **Phantom** (for Solana). * **Crucial**: Switch your wallet network to the **Source Chain** where your **wXLA** is currently held (e.g., Ethereum Mainnet or BSC). 2. **Configure Transfer**: * **Select Source**: Choose the chain where your wXLA resides (**Ethereum**, **BSC**, or **Solana**). * **Select Target Chain**: Set the destination to **Scala Network**. * **Enter Amount**: Input the amount of **wXLA** you wish to unwrap. * **Enter Destination Address**: Paste your **Scala Network address** (your MetaMask address configured with Scala RPC). 3. **Submit Swap**: * Click **Submit Swap** (or **Unwrap**). * Sign the required transactions in your wallet: 1. **Approve**: Allow the bridge to burn your wXLA. 2. **Confirm Transfer**: Initiate the burn process on the source chain. 4. **Transfer Completion**: * The bridge burns your wXLA on the source chain and releases native **XLA** on the Scala Network. * Wait for the finality period. The native **XLA** will arrive at the **Scala address** you provided. * Switch your MetaMask network to **Scala Network** to view your updated balance. # Exchanges Trade and exchange the Scala Coin {% embed url="" %} TradeOgre (BTC) {% endembed %} {% embed url="" %} TradeOgre (LTC) {% endembed %} {% embed url="" %} TradeOgre (USDT) {% endembed %} {% embed url="" %} TxBit (USDT) {% endembed %} {% embed url="" %} SevenSeas (USDT) {% endembed %} {% embed url="" %} Xeggex (BTC, USDT) {% endembed %} {% embed url="" %} BTDEX {% endembed %} {% embed url="" %} Exbitron (BTC, XMR, DOGE, USDT) {% endembed %} # FAQ Frequently Asked Questions About Scala. ## My balance is incorrect or shows 0 If you open your wallet and your balance is not showing the proper value, chances are your wallet is out of sync. Check to see if your wallet is syncronized by comparing your wallet blockheight with the network blockheight found on the Scala [Block Explorer](https://explorer.scalaproject.io/). If your wallet is out of sync, follow these simple steps: **For Scala Electron GUI Wallet:** 1. Visit the "settings page" located within the tab bar at the top left hand corner of your Scala wallet. 2. Once in settings, navigate to the two bars at the top, and make sure that you are on a working node. To find working nodes you can visit our Scala Discord channel. 3. Save your changes, the wallet will ask you to restart in order to apply. Restart wallet, and log in to your wallet account. 4. Allow the Scala wallet to fully synchronize, this may take several minutes to complete. **Scala CLI Wallet Local Node:** 1. Within the scala Daemon command prompt type, "status." Record the blockhight of your local daemon and compare it with the network blockheight on the [Scala Block Explorer](https://explorer.scalaproject.io/). 2. If your blockheight is incorrect, type in to the command line: Pop\_blocks 5000 3. Allow the Scala daemon to fully synchronize with the blockchain. After it is finished synchronizing, again type, "status." The blockheight should return the correct value. 4. Open up the CLI wallet and sign in to your wallet account. Let the wallet verify with your newly synced ledger ## Restore your Scala wallet from seed Always save your Mnemonic seed words in a safe, private location anytime you create a new wallet. To access your wallet on a new device, or restore your wallet, you can enter your Mnemonic seed words into the wallet system. **For Scala Electron GUI Wallet:** 1. Open your Scala Electron GUI wallet. 2. At the top right of your wallet main page screen you will see a "+" symbol tab. Within that tab select, "restore wallet from seed." 3. Choose a name, and password for your new wallet. 4. Copy and paste your Mnemonic seed into the correct bar. 5. Select, "restore wallet." **Scala CLI Wallet:** 1. Locate the Scala directory on your computer. 2. Within the Scala directory, create a new text file. 3. Open the text file and within it add: scala-wallet-cli.exe --restore-deterministic-wallet 4. Save the text file to your Scala folder as a .bat file. 5. Run the .bat file, follow the onscreen instructions in the command line interface. 6. After you restore your wallet in the .bat-cli, open your CLI wallet and select your new wallet. ## How do I install and use the Scala CPU Miner? The XLArig miner is an application developped to mine XLA with CPU. Always be conscious of your processor temperatures and utilization, running equipment at high usage for long periods of time can result in malfunctions. Mine responsibly. **XLArig :** 1. Install the XLArig miner, located [here.](https://github.com/scala-network/XLArig/releases) 2. Extract the download to a location of your choice. 3. Open the XLArig folder, and create a new .text document within the folder location. 4. Within the .text document, paste the following text: xlarig.exe -o \ -u \ -p x --algo panthera 5. Save the .text document as a .bat, and run the new .bat file that you have now created in your XLArig folder. ## How do I install and use the Scala Android Mobile Miner? Scala Mobile Miner: 1. Download and install the Scala Mobile Miner from the Scala Github found [here.](https://github.com/scala-network/MobileMiner/releases) 2. After Installation, open the app and open settings within the options tab located on the top left hand corner of the app. 3. Once in settings, paste your pool info: \ and paste your Scala wallet address. 4. Choose the number of CPU cores that you wish to use in your *armv* processor. Save. (more cores = more hashes). Note: The more cores you use, the hotter the device will be, and the slower that it will operate. 5. Go back to the "Miner" page, and tap start on the bottom right hand corner of the screen. 6. View your mobile device hashrate located at the top left-hand side of the miner's page screen. Total = all miners hashrate connected to that pool combined. 7. Visit the "Statistics" page to view network and pool information. # Assets ## Logos

Rounded Logo

![Logo for exchanges and other platforms](/files/-MMv3WgSqneL4q7IhPfC) ![Logo for socia media](/files/-MMv3K9pm0Y_cwdoD3lN) ## Assets {% embed url="" %} Official Graphics {% endembed %} # Contact Us ## Contact ### Email: ### Twitter {% embed url="" %} ### Medium {% embed url="" %} ### Youtube {% embed url="" %} ### Reddit {% embed url="" %} ### Telegram {% embed url="" %} ### Discord {% embed url="" %} # Donate ## Donate/Support the project ### BTC Donation Address: 1XTLY5LqdBXRW6hcHtnuMU7c68mAyW6qm ### XLA Donation Address: SvkFLjR4DST5bAG8SSHWfta4MsCzRrDEPNx72cTetqcoPfkwi7cFA2sYGG2Tf51rQ9EMSPHVuzxeoS4Y7ieicg5A1M24A8TTW ### ETH Donation Address: 0x133a15dF7177823Dd407ca87A190bbE4585a ### LTC Donation Address: LeLK5hopvfArVyKtkZBzF3B5wj6rGrNUGk