Signum Mining

Signum Mining: Introduction

Signum mining is the foundation for adding blocks to the Signum blockchain.  There are two distinct processes; a preparatory stage referred to as plotting and a processing stage referred to as mining.  This unique division differentiates Signum’s proof-of-capacity consensus algorithm from its functional counterpart, the proof-of-work consensus algorithm. It earns Signum the designation of “environmentally friendly”.

  • Stage 1: Plotting software pre-computes and stores the results of cryptographic hash functions in plot files.  These plot files contain the data and computations necessary to forge blocks, including so-called deadlines.  Because the calculations are retained rather than discarded immediately (as is done in traditional “proof-of-work” systems), mining capacity increases over time.  Plotting satisfies the “nothing at stake problem” and can be considered a modified proof-of-work component.
  • Stage 2: Mining software reads quickly through a subset of the data contained in the plot files and submits the best deadline (cryptographic solution) to the Signum network.*  The miner submitting the best deadline is granted the right to forge the related block and earns the associated block rewards and transaction fees.

*Signum employs a sophisticated and decentralized API network to verify and record transactions within its distributed and immutable ledger.


Plotting is the preparatory stage that precedes Signum mining.  Signum plotting solves the “nothing at stake” problem and can be considered a modified proof-of-work component.  It is temporary by nature as a preparatory stage and not comparable to the continuous proof-of-work implemented by other coins that use proof-of-work as their consensus algorithm.

Software pre-computes and stores all of the information necessary for forging Signum blocks, including a so-called deadline.  While there are multiple operations at work, such as division and string operations, the most notable calculations are based on the Shabal-256 cryptographic hash function.  Shabal-256 is relatively slow and heavy when compared to other cryptographic functions such as SHA256.  Selected for these characteristics, Shabal-256 slows the rate of plot file creation while remaining fast enough for the live verification used in Signum.  Mining software retrieves these hashes to find values for forging blocks.

Plot files are bound to Signum account IDs, so different account IDs always generate unique plot files.  Plot files created on a computer with a faster CPU are transferable to be mined by a computer with a slower CPU.  As a general rule, when using GPU-capable plotting software, reserve the GPU exclusively for plotting for the duration of the plotting session to avoid creating corrupted plot files.  Some software may include innovations that prevent this.

Avoid creating duplicate or overlapping plot files.  Duplicate or overlapping plots will not cause a malfunction and may go unnoticed.  However, they are of no value in the mining process.  To avoid creating overlapping plot files, carefully enter a correct starting plot number for each plotting session.

Engraver, a dedicated easy-to-use plotting program, can be found in the Signum software library.  TurboPlotter9000 is a good option if you have an SMR drive available to use as a staging drive.  BTDEX is the perfect all-in-one solution for beginners.


Capacity consists of the total stored computed hashes contained in plot files.  A small fraction of these files (around 0.025%) are read each block interval.


In addition to capacity, miners can lock an amount of Signa (stake) to multiply the physical capacity (statistically) resulting in a larger “effective capacity”.  The chain compares committed balances with the average for all miners over the last 1,440 blocks and applies the staking benefit to the deadlines submitted.


Without commitment, physical capacity is reduced by a factor of 1/8. Committing an amount equal to the average commitment results in a multiplying factor of 1.  Committing 100 times the average commitment increases effective capacity by a factor of 8.  The relationship of commitment and factor at all levels is linear.

A mining proceeds calculator can be found here:  Mining Proceeds 

Solo mining and pool mining:

A solo miner benefits only from those plot files which are specifically bound to their account.  If a solo miner submits the best deadline to the network, they alone will be credited with the total block reward and 100% of the transaction fees associated with that block.  Because the probability for any individual to forge a block is low, consistent success with solo mining requires many plot files.  With the current size of the network, successful solo mining requires multiple terabytes of storage capacity.  However, it is not unusual for a small miner to choose solo mining with the objective of network decentralization.  In this case, however, profit is not the primary objective.

Pool mining is the alternative to solo mining.  With pool mining, individual miners contribute their capacity to a cooperative group that shares the revenue earned according to their reward distribution policies (generally proportionally).  Most small-capacity miners prefer pool mining because it provides a stream of smaller but more regular payments.  You can join any pool by initiating a reward assignment transaction or by making a selection from the preconfigured list of pools in your wallet software.  There is also a list of pools in the online services section.

Anyone with the requisite technical expertise can operate a mining pool using software developed by the Signum community.

Step 1

Plotting software pre-computes and stores the result of cryptographic hash functions in plot files.

Step 2

Mining software reads a subset of plot file data and submits the best deadlines to the network.


BTDEX is a program that performs steps 1 and 2 seamlessly.  Perfect for beginners.

Solo Mining

Earn 100% of the block reward and related fees when you go-it-alone.

Pool Mining

Add your capacity to a community group and share the rewards earned by the group proportionally.

Reward Assignment

An on-chain transaction that joins your account to a mining pool.

Block Rewards

The rewards for each block diminish by 5% each month with a minimum block reward of 100.

Mining Capacity

Mining capacity is determined statistically based on the frequency and quality of submitted deadlines.


Stake is the amount of Signum that is locked in order to increase effective capacity.

Reward Assignment:

Reward assignment is a transaction that notifies the network that all block rewards attributed to your plot files are to be assigned to another account.  It is the mechanism that allows a pool to receive the block rewards that it distributes to its participants.  Reward assignment grants permission for the blocks forged using your submitted deadlines to be signed by the mining pool’s account.

Find the reward assignment transaction in the drop-down menu in the upper left corner of the Phoenix wallet or behind the gear icon in Signum Node.  In BTDEX, the reward assignment is accomplished by the “Join Pool” button located in the Mining tab.

After selecting “Reward Assignment”, enter the recipient account address in Reed Solomon format, the minimum transaction fee (.00735), your passphrase, and click on “Set Reward Recipient.”  Reward recipient transactions become effective after four confirmations, so it takes an average of 16 minutes to become effective on the blockchain.

New accounts created in BTDEX and Phoenix are provided with a small amount of Burstcoin to cover the transaction fee.  Accounts created with BRS can also receive this small amount if they are imported into Phoenix temporarily to make use of that wallet’s “account activation” functionality.  Another option is to operate a full node and receive SNR awards to fund the reward assignment transaction fee.  This award is paid daily and is a good way to supplement your mining revenue.  You can also make a request for the amount needed in a Burstcoin forum.  The recommended forum for this purpose is Burstcoin Discord.  Requests for the amount needed are usual and welcomed.

Some pools have a free option that allows you to set your reward assignment directly on their website.  This involves entering your passphrase into an online form.  It is important to remember that after an account’s passphrase has been entered into an online form, it can never again be considered secure.  For collecting mining proceeds, this may not be a problem.  Just remember not to use the account in the future for any large amounts.

Note:  It is possible to set the reward recipient directly using the API.  However, this method is technical and mostly used in software development.

Mining Capacity and Effective Plot Size:

Mining capacity, the total amount of storage capacity devoted to plot files, is the determining factor when choosing between mining methods.  It can also inform the choice of which mining pool to join.  There are no strict rules for making this decision and no technical obstacles preventing anyone with a particular mining capacity from joining any specific pool.  Distribution policies are usually stated using two numbers.  The first represents the percentage of the block reward paid to the account providing the winning cryptographic solution.  The second referred to as “historical share”, represents the percentage of the block reward distributed among the remaining participating miners.

For illustrative purposes, the following unofficial selection of common Signum mining distribution methods is provided.  Each is paired with a suggested mining capacity:

Distribution Successful Forger Historical share Mining capacity (in terabytes)
0 – 100 0% 100% 0 – 40
20 – 80 20% 80% 30 – 80
50 – 50 50% 50% 60 – 200
80 – 20 80% 20% 150 – 250
100 – 0 100% 0% 150 and higher

Please note:  Distribution methods are decentralized and set solely by individual pool operators.  This schedule does not address fees that a pool operator may charge.  Pool operators may also set their payment schedules and minimum payouts independently.  With the recent introduction of multi-out transactions, pools have additional flexibility.  Some have elected to pay rewards daily.

Effective plot size is the parameter used to determine each miner’s share of a pool’s mining revenue.  The method to calculate this statistic is set independently by each pool operator.  It is commonly calculated based on the best deadlines submitted by a miner over 360 blocks.  It typically starts at zero for a new miner and rises to reflect total capacity over 24 hours.  Because it is generated statistically, it will usually oscillate above and below the actual physical capacity.  You can optimize this calculation by limiting the maximum deadline to be submitted according to your pool’s specifications.

Block Rewards:

Mining revenue consists of block rewards and transaction fees.

Signum block rewards reduce after every 10,800 blocks (approximately once per month), subject to a minimum block reward of 100. The general formula for calculating the block reward based on the current block height is as follows:  max((month = block height / 10800reward = 10000 * 95^month / 100^month),(100))

For a schedule of block rewards, see the end of this document.


Technical Information:

public static long getBlockReward(int height) {

if (height == 0 || height >= 1944000) {

return 0;


int month = height / 10800;



.divide(BigInteger.valueOf(100).pow(month)).longValue() * Constants.ONE_BURST;


The process of mining and forging blocks:  (Begin Technical Information)

A Signum Node (locally installed or accessed remotely) and Signum mining software (to compute deadlines from plot files) are required.

The mining software requests mining information from the node as follows:

  • new generation signature = Shabal-256 (previous generation signature, previous block generator)
  • base target value
  • new block height
  • generation hash = Shabal-256 (new generation signature, new block height)

From this information (API Example), the mining software produces the following:

  • scoop number = modulo 4096 (generation hash)

This number is used to select scoops (scoop data) from the plot files.  For each scoop, the following are calculated:

  • target = shabal-256 (scoop datageneration signature)
  • deadline = 1st 8 bytes (target / base target)

After all of the deadlines have been calculated, the lowest deadline (subject to the maximum deadline setting), if any, is submitted to the node, along with the numeric account ID that is bound to the related plot file, and the nonce number for the scoop data that was used to generate the deadline.  For solo mining, the passphrase of the account bound to the plot file is also passed.  For pool mining, the passphrase of the pool account is used.

Note:  Older mining software submitted multiple, subsequently lower deadlines as they were found, subject to the maximum deadline setting.  However, there is no reason to do this following the Sodium hardfork.

Upon receiving the deadline (or deadlines) from the mining software, the receiving node creates a nonce that will be used to find and verify the deadline.  If the deadline is verified, the node waits for the deadline to expire.  If a lower deadline is passed to the node while the original deadline is expiring, the node will wait for the new lower deadline to expire.  After the lowest deadline submitted to the node has expired, the node will check the network to see if a new valid block has already been announced.  If a new block has already been announced, the information will be discarded.  If a new block has not been announced, the node will begin forging a new block.

To forge a block, the node collects unconfirmed transactions and checks the validity of each transaction, signature, timestamp, etc.  It assembles as many transactions as possible until the maximum number of transactions per block is reached or all available transactions have been processed.  The constraints on including transactions are the maximum block payload of 179,520 bytes (176 kB) and the maximum number of transactions includable in a single block.  The theoretical maximum number of transactions is 19,200.

See Signum transaction processing for more information on how transaction processing works.

Once a node forges a block, it announces it to the network by connecting to peers and sending the block for verification and validation.

Note:  Transactions are stored separately from blocks.

Pools often set a maximum deadline.  Deadlines exceeding this limit are excluded when calculating historical shares.

Signum Mining Diagram

Block contents and block explorers:

Signum block explorers are used to view block information and contents.  Block explorers are provided by programmers and organizations within the Signum community.  Various block explorers can be found in the online services directory.  A selection of details for each block is also included in most wallets.

Information typically found in a block explorer:

  • Block version number – refers to the block format which determines what a block can contain.
  • Block height
  • List of included transaction Ids.
  • Payload hash – Sha256 hash of all the data included in the block payload.
  • Timestamp – time the block was forged – derived from the time of the Genesis block (August 11th, 2014, at 02:00:00)
  • Total amount of all included transactions
  • Total amount of transaction fees
  • Payload length
  • The public key of the account that forged the block.
  • Generation signature used to forge the block.
  • Sha256 hash of the previous block’s contents.
  • Previous block Id – first 8 bytes of the previous block hash converted to a number.
  • Cumulative difficulty – used to prevent “Nothing at Stake” problems during potential forks:  Calculation:  (previous cumulative difficulty + ( 18446744073709551616 / base target )
  • Base target that was used when the block was forged.
  • Nonce number used to forge the block.
  • AT – payload bytes of the AT if AT was added to the block.
  • Block signature – 64-byte hash generated from the forger’s private key and the block’s contents.

Hash Functions:

Hash functions reduce text or data to a 64-character string of characters.  Regardless of length or content, an original text produces an identical string of 64 characters each time;  The slightest change to the original results in a completely different string of characters.  Hash functions have many applications.  One is checking a program for alterations by comparing the hash it produces with a hash produced from a version that is known to be good, or at least the original.  If a program presented as original produces a different hash, this is evidence that it has been altered.

With Signum’s application of cryptology, each block contains the hash of the previous block so that each block in the chain is verifiable.  If an earlier block is changed, the hash for every subsequent block would have to be changed as well, a task that would take billions of years due to Signum’s strong cryptology.  New blocks are added approximately every four minutes.  This short window of opportunity precludes such a lengthy task.  Herein lies the security of the Signum blockchain.

Unlike Bitcoin, the problem is not solved by random guessing but by reading through plots that contain the results of pre-computed hash functions.  Each is evaluated to determine a deadline, the amount of time it would take for a plot to return an answer to the puzzle.  The account submitting the shortest valid deadline is authorized to sign the block and receive the block reward.

Newly-created blocks are distributed to the network by the account that creates them.

Technical information for creating plot files:

Following is the terminology necessary for understanding the plot file creation process in Signum mining:

  • Account ID:  The Signum account numeric ID that binds a plot file to a specific Signum account.
  • Shabal-256:  The principle cryptographic function used for Signum processes.
  • Seed:  A Shabal-256 argument.  It can be considered an input variable.
  • Hash:  In the context of Signum, the output of the Shabal-256 function.  Size on disk:  32-Byte (256-bit).  All hashes are stored with a final hash.
  • Scoop:  Scoops are the base level subdivisions of hash data in a plot file.  Each scoop contains two hashes.  Each scoop is assigned a unique number ranging from 0 – 4096.  Size on disk:  64 bytes.
  • Nonce:  Nonces are the top-level subdivision of hash data in a plot file.  Each nonce contains 4096 scoops.  Each nonce is assigned a unique number ranging from 0 to (( 2 ^ 64) – 1)  (0, 1, 2, 3 … 18,446,744,073,709,551,615).  The identifying number is pre-assigned and used as a seed in the nonce’s generation.  Because of this, each nonce has a unique set of data.  Size on Disk:  256 Kilobytes.
  • Plot file:  A computer file containing all of the data necessary for forging Signum blocks.  Plot file data is first subdivided by nonces and then by scoops.  Size on Disk:  minimum of 256 Kilobytes, maximum of total disk capacity.

Note:  Plot files contain only raw data.  There are no headers.  The filename includes all of the information needed by a user or miner. The formatting of the filename is as follows.

POC2 format: AccountID_StartingNonce_NrOfNonces

Generating a nonce:

Step 1:  Calculate the initial hash (#8191) from a seed comprised of the 8 byte account ID and the 8 byte nonce number.  Each subsequent hash number will decrease by 1 until the final hash number is 0.

Hash #8191 = Shabal256 ( 8 byte account ID, 8 byte nonce number )

Step 2:  Prepend hash #8191 to the initial seed, creating a new seed. Calculate hash #8190.

Hash#8190 = Shabal256 ( Hash#8191, 8 byte account I, 8 byte nonce number)

Step 3:  Prepend hash #8190 to hash #8191, creating the next seed. Calculate hash #8189.

Hash#8189 = Shabal256 (Hash#8190, Hash#8191,  8byte account ID, 8 byte nonce number)

Step 4:  Continue prepending each result to the last seed and running the calculation until completing 128 iterations. After the 128th iteration, the resulting seeds will exceed 4,096 bytes. For all remaining iterations, use only the last 4,096 bytes.

Step 5:  Calculate a final Shabal-256 hash of all 8,192 hashes and the original 16-byte seed.

Final Hash = Shabal256( Hash#0, Hash#1, Hash#2, ( . . . ) , Hash#8191, 8byte account ID, 8 byte nonce number)

Use the final hash to XOR all other hashes individually:

The XOR logical operator compares the 1st byte from each hash and outputs a ‘1’ if the bytes match or a ‘0’ if the bytes do not match.  The operation is performed for each byte position.

Hash 1 0 0 0 0 0 0 0 0
Hash 2 0 0 0 0 0 0 0 1
XOR 1 1 1 1 1 1 1 0
Hash 1 0 0 0 0 1 1 1 1
Hash 2 0 0 0 0 1 1 1 0
XOR 1 1 1 1 0 0 0



 As follows:


32byte Hash #8191 XOR 32byte Final Hash
32byte Hash #8190 XOR 32byte Final Hash
32byte Hash #8189 XOR 32byte Final Hash
( . . . )
32byte Hash #0 XOR 32byte Final Hash


When complete, the newly created nonce is stored in a plot file, and the process for generating a nonce repeats. Each subsequent nonce generated is added to the plot file. The number of nonces includable in a plot file is limited only by storage capacity.

POC2 format

The process for creating nonces described until this point encapsulates what is known as the POC1 format.  To address a largely theoretical “time-memory tradeoff” vulnerability with POC1, POC2 was created.  Creating the POC2 follows the POC1 format, but a final step is added to reorganize the data.  The nonce is divided into 2 halves (scoop numbers 0 – 2047 and scoop numbers  2048 – 4095).  The data in the 2nd half of each scoop in the lower numbers and the data in the 1st half of each scoop in the higher numbers are swapped.  The mirror scoop is calculated as 4095 – CurrentScoop.

Note:  Poc1 plots can till be used for mining, however, the reading speed of POC2 files is half the reading speed of POC1 files.  POC1 files can be upgraded to POC2 using a plot file converter.  The conversion process takes about as long as replotting, so most opt to replot rather than use the conversion process.  You can identify POC1 plot files by their filename, which follows the pattern of 15286677094439976801_64658021_19075408_19075408 (4 numbers separated by underscores).  POC2 plot files have only 3 numbers in their file name as follows:  15286677094439976801_1816799207619978854_456192.

Plot structure

Mining software reads from one or more plot files.  It opens a file, locates a scoop, and reads the data that the scoop contains.  If the plot file is not optimized for this process, the scoop locations will be in more than one location. In the following example, the software is looking for scoop #403.  The continuity is interrupted as the software must read scoop #403 from nonce 0 and then locate and read scoop #403 from nonce 1.  Optimization is the process that places all of the scoops from all of the nonces into one sector.

Recently developed software automatically optimizes plot files as they are written to storage.  Before this development, it was necessary to use a second program to regroup the data remedially.

Information deprecated with POC2 format:

Stagger – A group of nonces in a plot file. Each stagger has a stagger number equal to the number of nonces in the group. To find the number of groups in a plot file, the number of nonces is divided by the stagger number. If the stagger number is equal to the number of nonces in the file, there is only one group, and the plot file is completely optimized. If the division does not result in an integer, the plot file can be assumed to be broken. Files names under the POC1 format are as follows:

POC1 format: AccountID_StartingNonce_NrOfNonces_Stagger (deprecated)

Block Reward Schedule:

Month Date Height Reward
0 2014-08-11 0 10000
1 2014-09-11 10800 9500
2 2014-10-11 21600 9025
3 2014-11-11 32400 8573
4 2014-12-11 43200 8145
5 2015-01-11 54000 7737
6 2015-02-11 64800 7350
7 2015-03-11 75600 6983
( … ) ( … ) ( … ) ( … )
83 2021-07-11 896400 141
84 2021-08-11 907200 134
85 2021-09-11 918000 127
86 2021-10-11 928800 121
87 2021-11-11 939600 115
88 2021-12-11 950400 109
89 2022-01-11 961200 104
90 2022-02-11 972000 * 100

*The minimum block reward is 100 Signa for all blocks after block height 972000.


Information in this documentation is based on an article written by Quibus.  The documentation has been revised by decrescendo.  Latest revision 7/15/2021.  Content auditing for this document is appreciated.

2 + 5 =

Share This