Signum Payment Solutions: Transaction Types and Fees

Signum Payment Solutions

Signa is a digital currency designed for fast, secure, worldwide payments.

Using only an official wallet, payments can be sent to any recipient, at any time, anywhere in the world.  The same payment technology can also be incorporated programmatically into payment and control systems using the signum API.

Signum supports sending Signa from one account to another account, one to many accounts, and several advanced transaction types for a single minimum transaction fee.

  • Whether you send Signa across the globe or the street, the low fees and quick transfer times are the same.
  • There are no banks or brokers to delay the transaction or inflate the cost.

Always accessible, wherever you are:

  • Sending Signa worldwide is as simple as sending a text message or email from any internet-connected device.
  • You only need the recipient’s Signum address or alias to transact with them at any time.
  • Messages can be attached to each payment, either encrypted (only readable by the receiver) or public (can be seen by anyone).
  • The message can be up to 1,000 characters and does not incur any additional costs.
  • Messages are perfect for linking Signa transactions with data for any transactional-related processes you may have.

Minimum Fee

.00735 Signa for ordinary transactions

Send Money

1 to 1, 1 to many (same amount), 1 to many (different amounts). All for the same low minimum fee.

Transaction Types

One-to-One Transactions (Single Payments):  The most basic transaction type, single payments, are one-time payments of a single amount from one account to another.

  • Specify a Signum account as the recipient, the amount of the transaction, and the transaction fee.
  • Add a message of up to 1,000 characters (optional).  Messages are encrypted by default (visible only to the receiver), but can also be sent as plain text (visible on the blockchain to everyone).
  • Click “Send Signa”.

Multi-out Transactions:  Cost-effective methods for sending multiple payments as a single transaction, incurring a single transaction fee.

  • Send Signa to up to 128 unique recipients if the amount sent to each is the same.
  • Send Signa to up to 64 unique recipients if the amount sent to each is different.
  • If the amount to be sent to each recipient is the same, check the “same amount” option.

Subscription Plans:  Methods for making recurring payments (similar to standing bank orders).

  • Set the amount to be sent at each interval.
  • Set the time interval for sending each payment (from at least 60 minutes to several days or months).
  • A message can also be attached and sent to the recipient at the start of the subscription.
  • Subscription plans are executed as scheduled regardless of network load.
  • There is no limit to the number of subscriptions payments in a block.

Encrypted Notes to Self:  Leverage a zero payment to send messages to yourself or others.

  • Start a regular transaction.
  • Enter your account number as the recipient.
  • Add a message.
  • Set the payment amount to zero.
  • Send the transaction.

Advanced Transaction Options

Custom Deadlines:

  • Deadlines set the duration of a transaction’s pre-confirmation validity.
  • The default, and maximum allowed, is 24 hours.
  • If a transaction is not confirmed by the deadline, it is deleted from the pool of unconfirmed transactions and must be re-issued.

Conditional Execution: This allows for one transaction to be conditioned upon the confirmation of another.  The mechanism works as follows:

  • A transaction with hash txhash1 has been issued.
  • Transaction tx2 is created.
  • If the txhash1 is provided as the “References Transaction Hash” in tx2,
  • txwill only be executed after txhas been confirmed.

Do Not Broadcast Option:  Prevents a signed transaction from being broadcast.

  • When the “Do Not Broadcast” option is checked, the raw transaction details are displayed to save to a separate file.
  • To broadcast the transaction later, the raw transaction details must be retrieved and entered in a separate wallet function.
  • This option is generally used in combination with Offline Transaction Signing.

Offline Transaction Signing:  A method for keeping private keys on an offline device (never exposing them to the internet).

  • Individual transactions are signed on an offline device and then copied to an online device to be broadcast.
  • The transaction that is broadcast contains only a single-use signature, so this practice is virtually risk-free.
  • Access “Transaction Operations”
  • Enter the signed transaction bytes
  • Click “Broadcast”

Note:  In addition to signing transactions from an offline device, signing can also be done on an online device but still performed locally.  Assuming the computer is malware-free, this is the most convenient option while still keeping private keys safe.  Signum Node uses this form of signing for its wallet interface through locally run JavaScript.

Transaction Fees

(This section is being updated to reflect implementation of CIP 31, Which replaces the slot-Based Fee system shown in the next section.  The information in this section is not exactly accurate at this time but serves to outline the general handling of transaction fees while the exact schedule is being clarified.)

Transactions fees in Signum are fully market based.  This means that an entire block must be full before a transaction paying the minimum transaction fee would be delayed.

Minimum transaction fee (referred to as “fee quant”)

  • .00735 Signa

Most transaction fees are charged based on the byte size of a transaction on-chain.  The base formula is as follows:

  • Transaction Fee = .00735  * floor (transactionBytes / 176):  Note:  With the “floor” function, results are rounded down to a whole number.

Following are examples of transactions that fall within the limits of the minimum fee of .00735 (transactions that are 352 bytes or less on-chain).

  • Ordinary Transactions:  Size on-chain:  176 bytes
  • Ordinary Transactions with small attachments:  size on-chain:  up to 352 bytes
  • Simple messages:
  • Transaction to add commitment:  Size on-chain: 184 bytes
  • Deposits to an exchange (with or without memo):  Size on-chain: 245 bytes
  • Token order:  Size on-chain:  201 bytes
  • Ordinary  transactions to extended addresses (with public key attached):  Size on-chain: 209 bytes
  • Transactions to create a subscription: Size on-chain: 181 bytes

The following examples have a fee that is greater than the minimum fee (due to their byte size on-chain).

  • Ordinary transaction types with a large attachment:
  • Multi-out transactions with the maximum number of recipients:  Size on-chain:  1200 bytes:  Transaction Fee = .00735 * floor (1200 bytes / 176) = .0441
  • Message with a large attachment:  Size on-chain:  1200 bytes:  Fee = .00735 * floor (1200 bytes / 176) = .0441

The minimum fee structure is designed to maximize the throughput of value and information that can be moved efficiently on-chain.  The larger fee, based on multiples of 176 bytes, serves to limit the amount of blockchain growth.

Certain transactions, such as issuing a token series, transferring an alias, or creating a smart contract are higher level blockchain services and are subject to a multiplier that is referred to as factor.

  • Assign an alias:  Size on-chain:  1200 bytes:  Transaction fee based on byte size =.00735 * floor (1200 bytes / 176) = .0441:  A minimum fee of 20 applies to this transaction:  Resulting Fee = 20.
  • Transfer an alias:
  • Create a smart contract:

Signum wallets have a transaction fee suggestion tool that evaluates current on-chain activity levels so that the sender has ready information when choosing a fee.  Following are the 3 recommendation tiers: 

  • Budget: 50% probability the transaction will be included in the next 10 blocks
  • Standard: 50% probability the transaction will be included in the next block
  • Priority: 90% probability the transaction will be included in the next block, 99% probability the transaction will be included in the next two blocks.

The fee suggestion tool is made available through the Signum API.

Transaction Fees

(Deprecated with implementation of CIP 31, will be archived shortly)

Minimum transaction fee (sometimes referred to as “fee quant”)

  • .00735 Signa (735.000 Plancks).

All transaction types use the following slot-based transaction fee schedule.

1: 0.00735 - 0.01469
2: 0.01470 - 0.02204
3: 0.02205 - 0.02939
4: 0.02940 - 0.03674
5: 0.03675 - 0.04409
6: 0.04410 - 0.05144
7: 0.05145 - 0.05879
8: 0.05880 - 0.06614
9: 0.06615 - 0.07349
10: 0.07350 - 0.08084

This schedule continues linearly up to 1020 for which the highest fee of 7.49700 Signa is charged, each slot holding one transaction.  The minimum fee for each slot is the minimum transaction fee (fee quant) multiplied by the slot number.  The total fees collected for a block where all slots are filled with the minimum required fee is 3827.2185 Signa.

Transactions are assigned to the slot for which the fee range includes the transaction’s specified transaction fee.  For example, a transaction with a specified fee of .03 would be assigned to slot #4 because it falls within the range of 0.02940 - 0.03674.  The amount by which a transaction’s specified fee exceeds the minimum fee for the slot to which it is assigned is not refunded.  It is up to the user to choose a reasonable fee that does not waste funds.

If no slot is available, a transaction remains unconfirmed in the memory pool until a slot becomes available in a future block or until its deadline for inclusion has expired.

The slot-based transaction fee system serves as a disincentive for creating spam transactions that would otherwise require little or no investment.  This conserves blockchain space and keeps the cost of operating a public node at a minimum.


Assuming a block capacity of 10 transactions, transactions with specified fees of .07350, .07000, .05900, and .00800 would be assigned slots as follows:

.07350 to slot 10
.07000 to slot 9
.05900 to slot 8
.00800 to slot 1

The Signum wallet is equipped with a tool that suggests a transaction fee based on the transaction load over the last 10 blocks.  The suggested fees are as follows:

  • Budget: 50% probability the transaction will be included in the next 10 blocks
  • Standard: 50% probability the transaction will be included in the next block
  • Priority: 90% probability the transaction will be included in the next block, 99% probability the transaction will be included in the next two blocks.

The fee suggestion tool is made available through the Signum API.

Technical Information for developers:

Maximum number of transactions per block:  Every 4 minutes, a new block is created with the following attributes:

  • Maximum Size: 179,520 Bytes
  • Maximum Transactions: 19,200 (multi-out)
  • Maximum Transactions per second: 80
  • Maximum number of Subscription Plans:  Unlimited

Ordinary transactions are those transactions that are subject to the minimum transaction fee:

  • send money
  • create alias
  • transmit message
  • issue asset
  • order asset

Server-Side Online transaction signing:

Although it is possible, it would only be considered “safe” to do this using localhost. If you are developing/distributing software, do not present online signing as an option to your clients. You will make them a potential target for malicious actions.

Implementing transaction signing:

Transactions must be signed before they can be broadcast.  Use one of the API functions to request transactionBytes from a node. The returned JSON object contains the transactionBytes that represent the transaction to be made.

It is important to use the publicKey argument rather than  secretPhrase for the transactionBytes request.  Also, to set the broadcast argument to false to prevent broadcast.

To sign the transactionBytes locally, refer to these sources below to include the signing functions in your code.

Code sources


function signTX(unsignedTransactionBytes) { myBytes = unsignedTransactionBytes // keep a copy signature = crypto.sign(unsignedTransactionBytes, passPhrase) // make the signature myBytes.copy(96, signature); // copy the signature over the unsignedTransactionBytes with a offset of 96 bytes return myBytes}


  • Add signature and TransactionBytes length
  • Compare and verify your implementation with the requestType: Sign Transaction.
  • The transaction is now signed and can be broadcast (through POST only):  Refer to Signum Node API Transactions.

6 + 6 =

Share This