SRC-20 Multi-XFER Tokens - BULK TRANSFER

[reinamora137]

Add the ability to have multiple destination addresses on a transfer

This will require full support amongst OKX and Steve's indexer and is a consensus change. It is proposed to ignore the btc trx output which typically is the destination address, and only use the destinations indicated in the json field.

Problems with this design are invalid BTC addresses in the destination field. Will only the invalid addresses be ignored and that balance retained by the owner or will the entire transfer be invalid?

Requirements:

• what happens to the typical destination address on the btc transaction output. (PROPOSED: ignore)
• what happens if any of the btc addresses are invalid? (PROPOSED: entire transfer is invalid)

This change will also accept the op XFER for single transfers op value

[reinamora137]

{
 "p": "SRC-20",
 "op": "XFER",
 "tick": "LUFFY",
 "transfers": [
   {"amt": "1000", "dest": "dest1"},
   {"amt": "100", "dest": "dest2"}
 ]
}

Need to potentially add support for bulk transfer locking

{
 "p": "SRC-20",
 "op": "XFER",
 "tick": "LUFFY",
 "transfers": [
   {"amt": "1000", "dest": "dest1", "lock_amt": "10", "unlock_block": "899999"},
   {"amt": "100", "dest": "dest2", "lock_amt": "1", "unlock_block": "899999"}
 ]
}

[reinamora137]

Possibly just consolidate this to use XFER as the op for both transfer and multi-transfer. if we detect the transactions key (or some other variation of that name) then we process bulk.

{
 "p": "SRC-20",
 "op": "XFER",
 "tick": "LUFFY",
 "transactions": [
   {"amt": "1000", "dest": "dest1", "lock_amt": "10", "unlock_block": "899999"},
   {"amt": "100", "dest": "dest2", "lock_amt": "1", "unlock_block": "899999"}
 ]
}

{
 "p": "SRC-20",
 "op": "XFER",  --- could be added to be valid
 "tick": "LUFFY",
 "amt": 1010000
}