Phasing.
Phasing API calls:
ApproveTransaction, GetAccountPhasedTransactions,
GetAccountPhasedTransactionCount, GetAssetPhasedTransactions,
GetCurrencyPhasedTransactions, GetPhasingPoll, GetPhasingPolls,
GetPhasingPollVote, GetPhasingPollVotes, GetVoterPhasedTransactions.
A transaction of any type can be phased by adding a phased=true parameter and
an appropriate set of phasing parameters. Phased transactions are accepted in
the blockchain immediately (subject to all usual validations), but are executed
only at finish height, if still valid and if the required quorum has been met.
If not approved, or not valid at finish height, they remain in the blockchain
but are never executed, and any changes they caused to the sender unconfirmed
balance are reversed, except that the fee is not refunded.
In addition to the voting models available in polls, phased transactions can
use a whitelist of accounts (max 10) allowed to vote for the transaction.
It is possible to vote for (approve) up to 10 phased transactions with a single
approval transaction. This transaction will be accepted in the blockchain only
if all phased transactions it is voting for are already in it.
Voting multiple times is allowed but has no effect on vote counting, votes
after the first vote from each account are ignored.
It is also possible to make any transaction phased without needing voting for
approval. This can be used to create transactions with deferred execution.
Pay on reveal secret is supported as a voting model for phased transactions.
When this voting model is used, the phased transaction must include the
hash of a secret chosen by the sender (up to 100 bytes long), and an approval
transaction for it is only accepted if it includes the secret that results in
this hash. It does not matter who the sender of the approval transaction is,
unless a whitelist is also defined. Supported hash functions currently are
sha256, ripemd160, and sha256 followed by ripemd160. The codes to specify them
as parameters are available from the getConstants API.
Finally, it is possible to make a phased transaction that is released or
rejected not on the basis of voting, but based on the presence of other
transactions (linked transactions) in the blockchain at its finish height.
To do that, up to 10 phasingLinkedFullHash transaction hashes can be defined
when creating the phased transaction. Note that this does not create a
dependency between the linked transactions themselves. This feature can be
used to implement atomic execution of transactions of any type, provided the
phased transaction is phasing safe. Transactions already in the blockchain
before the acceptance of the phased transaction can also be linked, as long
as they are not more than 60 days old, or themselves phased transactions.
The deferred execution with no approval needed, pay on reveal secret, and
linked transactions features are currently accessible using the API only, the
UI for them will be completed in a later release.
Similar to voting, the phasing data for phased transaction that finished before
the last trim height is also deleted and only the aggregate approval results
are kept.
The fee for making a transaction phased depends on the voting model selected.
For by-account voting with no minimum balance, or no voting needed, it is 1 NXT
in addition to the regular fee for that particular transaction type. For voting
that depends on voter balances, the additional phasing fee is 20 NXT.
The fee for approving a phased transaction is 1 NXT for each phased
transaction included in the vote.
Full message here: https://nxtforum.org/nrs-releases/nrs-v1-5-0e/ (remember, testnet version only at this stage)
Just querying the answer I got. 
