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

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.

Examples:

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

Pseudocode:

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}

Notes:

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

8 + 12 =

Share This