Skip to content

Instantly share code, notes, and snippets.

@reardencode

reardencode/dumb.md

Last active January 3, 2025 22:58
Show Gist options
  • Save reardencode/ac8817ce986580545b5ebb3555ccfbd3 to your computer and use it in GitHub Desktop.
Save reardencode/ac8817ce986580545b5ebb3555ccfbd3 to your computer and use it in GitHub Desktop.
Download ZIP
LNHANCE+CCV+AMOUNT AMM
Raw
dumb.md

What?

OP_CAT token and AMM construction

Before I begin this section, let me just say that an AMM (Automated Market Maker) is only an example of the type of protocol that we should be considering, it is not in itself the problem. Because it requires several capabilities currently missing from bitcoin, it is a useful example.

Given the existence of the CATNIP token design as discussed by Ademan and myself before Rijndael and crew wrote it down in some more detail, we can identify certain requirements for building a script-verifiable token standard on bitcoin.

  • First and foremost, to build a script verifiable token standard, bitcoin needs some way for a contract to enforce that it is attached to successive UTXOs either in perpetuity or effective perpetuity. This can be achieved by unrolling a non-perpetual contract many millions of steps, or by having a perpetual self-enforcing contract.
  • Second, we require a say to attach transfer instructions to a token input. This can be done by using the OP_CAT caboose technique, or using constructions like OP_VAULT or OP_CCV plus some mix of transaction and stack signatures. In either case, we need a way to carry multiple data items together - CAT+SHA256 or PAIRCOMMIT achieve this.

With the above, we have enough to build a token standard, but with no AMM. To build a token-token AMM, we need multiplication between token values and rates. If token balances are limited to 31 bits and exchange rates are limited to small integers then this can be implemented using a Merkelized lookup table (e.g. using a taptree where each leaf implements a different excahnge rate using an addition ladder and checks the input token balances to authorize using that rate).

// TODO: fractional exchange rates?

To then build an AMM between bitcoin and tokens, we need a script that is able to deal with bitcoin amounts. Naively this requires 53-bit math operations which can be emulated using OP_CAT to concatenate results. In the absence of OP_CAT, a more limited version can be implemented using an addional Merkelized lookup table to map from 31-bit results to corresponding 53-bit bitcoin amounts.

// TODO: Can all values be mapped this way? I htink not. *

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment