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:
- 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.
- 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.
- 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.
- 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.
- Only 1 mint baton: Sometimes it massively simplifies an implementation if multiple mint batons are allowed. SLP allows this.
Features of ALP
- Multi-token atomic swaps: Within a single transaction, multiple tokens can be swapped atomically.
- Extensible: Other protocols can append their own pushdata, which allows novel interactions with tokens.
- 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.
- 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.
- 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
- 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.
- 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