Historical Reference

🚧

New site!

All content has been migrated to docs.dash.org. You will be automatically redirected momentarily.

❗️

Deprecated Content

The following information is deprecated and for historical reference only. It describes features that have been redesigned and no longer operate as described below.

InstantSend (original)

🚧

Please see here for details of the current InstantSend design.

Dash Core's InstantSend feature provides a way to lock transaction inputs and enable secure, instantaneous transactions. Since Dash Core 0.13.0, any qualifying transaction is automatically upgraded to InstantSend by the network without a need for the sending wallet to explicitly request it. For these simple transactions (those containing 4 or fewer inputs), the previous requirement for a special InstantSend transaction fee was also removed. The criteria for determining eligibility can be found in the lists of limitations below.

The following video provides an overview with a good introduction to the details including the InstantSend vulnerability that was fixed in Dash Core 0.12.2. Some specific points in the video are listed here for quick reference:

• 2:00 - InstantSend restrictions
• 5:00 - Masternode quorum creation
• 6:00 - Input locking
• 7:45 - Quorum score calculation / Requirement for block confirmations
• 9:00 - Description of Dash Core pre-0.12.2 InstantSend vulnerability
• 13:00 - Description of vulnerability fix / Post Dash Core 0.12.2 operation

InstantSend Data Flow

InstantSend Client	Direction	Peers	Description
inv message (ix)	→		Client sends inventory for transaction lock request
	←	getdata message (ix)	Peer responds with request for transaction lock request
ix message	→		Client sends InstantSend transaction lock request
	←	inv message (txlvote)	Masternodes in the quorum respond with votes
getdata message (txlvote)	→		Client requests vote
	←	txlvote message	Peer responds with vote

Once an InstantSend lock has been requested, the instantsend field of various RPCs (e.g. the getmempoolentry RPC) is set to true. Then, if a sufficient number of votes approve the transaction lock, the InstantSend transaction is approved the instantlock field of the RPC is set to true.

If an InstantSend transaction is a valid transaction but does not receive a transaction lock, it reverts to being a standard transaction.

There are a number of limitations on InstantSend transactions:

• The lock request will timeout 15 seconds after the first vote is seen (INSTANTSEND_LOCK_TIMEOUT_SECONDS)
• The lock request will fail if it has not been locked after 60 seconds (INSTANTSEND_FAILED_TIMEOUT_SECONDS)
• A “per-input” fee of 0.0001 DASH per input is required for non-simple transactions (inputs >=5) since they place a higher load on the masternodes. This fee was most recently decreased by DIP-0001.
• To be used in an InstantSend transaction, an input must have at least the number confirmations (block depth) indicated by the table below

Network	Confirmations Required
Mainnet	6 Blocks
Testnet	2 Blocks
Regtest	2 Blocks
Devnet	2 Blocks

There are some further limitations on Automatic InstantSend transactions:

• DIP3 must be active
• Spork 16 must be enabled
• Mempool usage must be lower than 10% (AUTO_IX_MEMPOOL_THRESHOLD). As of Dash Core 0.13.0, this corresponds to a mempool size of 30 MB (DEFAULT_MAX_MEMPOOL_SIZE = 300 MB).

Historical Note

Prior to Dash Core 0.13.0, instantsend and instantlock values were not available via RPC. At that time, the InstantSend system worked as described below.

Once a sufficient number of votes approved the transaction lock, the InstantSend transaction was approved and showed 5 confirmations (DEFAULT_INSTANTSEND_DEPTH).

NOTE: The 5 "pseudo-confirmations" were shown to convey confidence that the transaction was secure from double-spending and DID NOT indicate the transaction had already been confirmed to a block depth of 5 in the blockchain.