Idea : Bet Encoded in Op_Return

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

1 Like