Currently bets are only partially encoded in op_return. The feed address is left out of op_return and instead is determined by sending a dust amount to it, typically 5040 satoshi ($0.12 at today’s rate).
This is wasteful.
The same is true for asset sends but CIP 9 will solve this issue. The recipient address will be encoded within op_return. This will eliminate the ~12 cents of dust and also make the transaction smaller, so the fee will be reduced too.
A hex encoded bet transaction is on the following format
434e545250525459|00000028|0002|54a08b70|0000000000989680|00000000004c4b37|3ff0000000000000|000013b0|00000009
Encoded is the following info (bytes)
prefix (8) + transaction id (4) + bet type (2) + deadline (4) + wager (8) + counterwager (8) + target value (8) + leverage (4) + expiration (4)
That’s a total of 50 bytes
(2 hex = 1 byte)
Op_return can take 80 bytes. This leaves 30 bytes unused. CIP 9 states that an address takes 21, so the feed address can definitely fit in op_return.
Asset Support
Betting currently only allows XCP to be used. If we want to allow asset betting, then assets too can be specified within op_return.
An asset name takes 8 bytes.
prefix (8) + transaction id (4) + bet type (2) + deadline (4) + wager (8) + counterwager (8) + target value (8) + leverage (4) + expiration (4) + feed address (21) + asset (8)
That’s a total of 79 bytes
Double Asset Support
If we want betting of one asset against another, we’ll need another 8 bytes for the second asset.
It’s possible if we make two optimizations:
- As in CIP 9, reduce address from 21 to 18 bytes by including 3 bytes in the transaction id
- Remove leverage since it’s never used. It’s been redundant ever since CTFs were disabled
prefix (8) + transaction id (3+1) + bet type (2) + deadline (4) + wager (8) + counterwager (8) + target value (8) + expiration (4) + feed address (18) + assetA (8) + assetB (8)
That’s an 80 byte perfect fit