The “Augmented Ledger Protocol”, a successor protocol to the great and beautiful Simple Ledger Protocol.

Rationale

SLP is an amazing token protocol. It’s used for much more than thought to be possible, e.g. self-minted tokens.

However, it also has some shortcomings:

  1. Reverse endianness: Everything in Bitcoin uses little endian, except for SLP, which consistently uses big-endian. This is a consistent footgun that SLP devs run into. ALP uses little-endian consistently as Satoshi intended.
  2. Squatty protocol: SLP takes over the entire OP_RETURN output and leaves no room for other protocols. ALP uses the eMPP protocol to allow for multiple sections of data.
  3. BigNum requirement: Despite only allowing 64-bit integers, SLP allows overflows, which often requires the usage of big num libraries, making implementations awkward. ALP forbids overflows, allowing the usage of commonly available numbers.
  4. Ghost outputs: SLP can send tokens to outputs that don’t exist. This adds unnecessary complexity to all developers, as this edge case will have to be handled by indexers and wallets.
  5. Only 1 mint baton: Sometimes it massively simplifies an implementation if multiple mint batons are allowed. SLP allows this.

Features of ALP

  1. Multi-token atomic swaps: Within a single transaction, multiple tokens can be swapped atomically.
  2. Extensible: Other protocols can append their own pushdata, which allows novel interactions with tokens.
  3. More compact: Since amounts are only 6 bytes (instead of 9), encoding is more compact and allows for more outputs under the existing 220 byte limit for OP_RETURNs. For example, while SLP only allows 19 outputs at most, ALP can have 29 outputs.
  4. Easier to implement: Despite having more features, ALP is actually easier to “get right”. By its design, it makes a lot of common SLP bugs impossible e.g. by simply leaving no space between fields. It also allows verifying amounts using only 64-bit integers and removes the requirement for 128-bit/BigNum libraries that SLP has.
  5. Double-precision-floating-point-number-friendly: Some languages only have double-precision floating point numbers (like JavaScript). In ALP, token amounts can always be represented accurately using those numbers (not in ALP).

Drawbacks

  1. Multiple tokens per transaction: While this has a lot of benefits, this also makes writing wallets, explorers etc. more difficult, as instead of having 0 or 1 token IDs per transaction, you can have a list of token IDs.
  2. Non-trivial “coloring” step: Since a ALP transaction can have many “sections”, each with their own token ID (which is not possible in SLP), indexers will have to implement “coloring”, which might be non-trivial.

Specification

Terms