All content has been migrated to docs.dash.org. You will be automatically redirected momentarily.
The following information is deprecated and for historical reference only. It describes features that have been redesigned and no longer operate as described below.
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
|→||Client sends inventory for transaction lock request|
|←||Peer responds with request for transaction lock request|
|→||Client sends InstantSend transaction lock request|
|←||Masternodes in the quorum respond with votes|
|→||Client requests vote|
|←||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
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 (
- The lock request will fail if it has not been locked after 60 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
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).
Prior to Dash Core 0.13.0,
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 (
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.
Updated 23 days ago