Skip to content

4.0.1 Nebula

Time critical update

The new voting mechanism, new transfers, and temporary delegate resignations will be available from block 1,175,000 on 15th July 2022.

Changes since 3.3.0

This is the first major update of Solar Core since the launch of Mainnet.

Click on the following link to read a full summary of the 4.x release:


  • Introduction of v3 transactions, featuring:
    • Combined Transfer and MultiPayment transactions
    • New Vote transaction type
    • New 'Temporary' and 'Permanent' 'Delegate Resignation' types
    • Optional Transaction Memos
  • Improved Core Crypto web browser compatibility
  • Tighter schema validation
  • Near-instantaneous fork recovery
  • CPU count-based service worker allocation
  • Improved logging and errors descriptions


Supported OS Release
Ubuntu >= 20.x
Debian >= 10.x

Ubuntu <= 18.x and Debian <= 9 are no longer supported

Relay Requirements Recommended Minimum
CPUs 4 2
HDD 100GB - 120GB 80GB
Forger Requirements Recommended Minimum
CPUs 4
HDD 100GB - 120GB

Update instructions

Note that this is not the usual solar update command!

Update your Mainnet node with the following command:

wget -4O- | bash

v3 transaction changes

There are several key transaction changes to be aware of in Solar Core 4.x.

The 'memo'

All Solar transactions now contain a special 255-byte data field known as a 'Memo' and allows raw data, code, or plain text to be stored on the blockchain. The Memo is optional, public, and immutable.

This was previously known as the vendorField and was only available on certain transaction types.

v3 transfer

TypeGroup Type
1 6

One of the most important changes is the introduction of the new Transfer transaction type.

Formerly, a single send transaction made use of v2-style Transfers (Type 0) whereas two or more sends required using a v2 MultiPayment transaction (Type 6).

Under Solar Core 4.x, these have been combined under the MultiPayment pattern and are now known simply as 'Transfer' (Type 6), removing the unnecessary requirement of two separate transaction types.

See the v3 Transfer structure here.

TypeScript Code Example:

const { Transactions, Managers, Utils } = require("@solar-network/crypto");
const { Connection } = require("@solar-network/client");

// Configure our API client
const client = new Connection("");

// Set the network configuration

(async () => {
    // Step 1: Retrieve the incremental nonce of the sender wallet
    const senderWallet = await client.api("wallets").get("YOUR_SENDER_WALLET_ADDRESS");
    const senderNonce = Utils.BigNumber.make(;

    // Step 2: Create the transaction
    const transaction = Transactions.BuilderFactory.transfer()
        .memo("This is an example memo")
        .addTransfer("Address of Recipient Wallet 1", 1 * 1e8)
        .addTransfer("Address of Recipient Wallet 2", 1 * 1e8)
        .addTransfer("Address of Recipient Wallet 3", 1 * 1e8)
        .sign("this is a top secret passphrase");

    // Step 4: Broadcast the transaction
    const broadcastResponse = await client.api("transactions").create({ transactions: [] });

    // Step 5: Log the response
    console.log(JSON.stringify(, null, 4))

See the Python code example here.

v3 Vote

TypeGroup Type
2 2

Voting has undergone a significant conceptual change in Core 4.x. Previously, a wallet could vote for only one delegate at a time. Under the new scheme, a wallet can vote for up to 53 delegates in total as well as optionally customise the distribution of their vote weight.

For instance, the default behaviour of voting for three delegates where no custom distribution is specified would look as follows:

        "votes": {
            "cactus1549": 33.34,
            "gym": 33.33,
            "sl33p": 33.33


Note that the vote weight is distributed evenly and uses a natural sorting order. Because the vote weight must total 100%, the remaining 0.01% is subsequently distributed in ascending order.

When manually specifying vote weight distribution, natural sorting is still used; however, vote weight is prioritised while determining the list's order. For example:

        "votes": {
            "sl33p": 40.50,
            "cactus1549": 29.75,
            "gym": 29.75


See the v3 Vote structure here.

v3 Delegate Resignation types

TypeGroup Type
1 7

Previously, v2-style Delegate Resignation was a permanent action. There was no way for a resigned delegate to reinstate their eligibility to receive votes and produce blocks. This was only useful in cases where a delegate no longer wanted to participate in network consensus.

Solar Core 4.x adds a new 'Temporary' resignation option where their resigned status may be 'Revoked' after at least two rounds (~106 blocks). This is useful when a delegate may only wish to resign for a short time without negatively impacting the network (e.g., missing blocks) and can be for a variety of reasons, from temporary node maintenance to personal/private matters.

Resignation Type Value Description
Temporary 0 Resign only for a short time.
Delegate will be temporarily blocked from receiving votes or forging.
(the default when no resign type is declared)
Permanent 1 Irreversible. Delegate will no longer be allowed to receive votes or forge.
Revoke 2 Reverses a temporary resignation.

See the v3 Delegate Resignation structure here.