mononaut/hop.md Secret

## hop.md

      
    Raw
  

              hop.md
            
          
    The Hop-Return Protocol: Introducing Non-Standard Tokens (NST)

Abstract

OP_RETURN outputs on Bitcoin have long been dismissed as mere data carriersâ��ironically, it's precisely their restrictive size limits that make pushing their boundaries compelling. The Hop-Return Protocol embraces the unconventional power of oversized, non-standard OP_RETURN payloads to enable standardized, secure token transfers on-chain. Extending this concept, NST (Non-Standard Tokens) implements structured, protocol-driven issuance specifically optimized for these large OP_RETURN transactions. This paper explores how the seemingly arbitrary constraints of OP_RETURN sizes lie at the heart of the protocol's appeal, detailing NST's issuance mechanics and highlighting the uniquely Cypherpunk opportunities unlocked by bending Bitcoinâ��s standard transaction rules.
Introduction

In the pantheon of token protocols, few have dared to fill entire blocks with a single transaction. The Hop-Return Protocol, defined as a meta-protocol using UTF-8 encoded JSON messages embedded in non-standard OP_RETURN outputs, serves as the transport layer for NST (Non-Standard Tokens). Together, they boldly harness the arcane power hidden within Bitcoin's OP_RETURN consensus limits. Thanks to services like Marathon Digital Holdings' Slipstream¹, non-standard transactions can be confirmed more reliably, much like Superman leaping fences with ease. We sincerely thank those advocating to preserve Bitcoin's standard OP_RETURN size limits. It's precisely these restrictions that make unconventional protocols like this possible. No specialized software is available at launch; instead, the NST ecosystem is governed entirely by social consensus, as defined in this document. Unlike Ordinals², Hop-Return uses an explicitly account-based system to transfer tokens through OP_RETURN outputs. Each NST using Hop-Return must include an OP_RETURN payload of at least 100 bytes, rendering it non-standard by current node relay policies. By embracing these constraints intentionally, NST reimagines whatâ��s possible on Bitcoin, opening new paths for tokenization, experimentation, and Cypherpunk creativity.
Mother of All Transactions (MOAT)

Affectionately known as the Mother of All Transactions (MOAT), this transaction marks the starting point of the NST ecosystem. The MOAT is an on-chain Bitcoin transaction consisting of two large OP_RETURN outputs: one containing this document, and the other an image commemorating the protocol's inception. All NST tokens are issued exclusively through transactions sent to the official MOAT address, which functions as the NST "dumb issuance contract." This approach shares similarities with Counterparty³, but without a burn, relying entirely on social consensus. The intentionally large OP_RETURN payload creates a barrier to replication, distinguishing legitimate MOAT transactions from smaller, insufficient attempts.
Official MOAT tribute address for issuance:
bc1pm0ther3jqnjz4n7342djtvkgq3rsu2g6qdr5wgkgm4slyvt343fsrg8p4w
Tributes and Receiving NST

To receive NST, the MOAT demands a tribute of at least 2001 sats along with an OP_RETURN payload of no fewer than 100 bytes; anything less is ignored. + Each OP_RETURN payload must begin with exactly one valid Bitcoin address, followed by a single space as a delimiter. You'll likely need a specialized service to get your transaction confirmed¹, as the OP_RETURN size will be non-standard, potentially making confirmation more costly. Standard Bitcoin relay rules typically prevent the propagation of such unique transactions, one of the protocol's distinctive traits, enhancing its uniqueness and appeal. Every transaction sent holds a special place in history as one that "broke the relay rules", very Cypherpunk!
Note: A 2000 sat base minimum is enforced to avoid creating dust UTXOs, helping maintain network health and more importantly prevent spam.
Token Issuance

When sending a valid tribute to the MOAT, you will not receive a UTXO or direct on-chain output. Instead, the specified Bitcoin address included in the OP_RETURN payload is credited automatically with NST tokens via the dumb issuance contract. The amount of NST received depends on the amount of sats sent and the current block height:
Issuance by heights:


On or before block height 909,420:
(amount in sats - 2000) * 2
From block height 909,421 to 1,000,000:
(amount in sats - 2000)
After block height 1,000,000:
No further issuance of NST v1 tokens allowed.

Examples:


Sending exactly 2000 sats or lower with an OP_RETURN of at least 100 bytes:
Result: 0 NST.
Sending a transaction on Block 900,005, sending 2001 sats with an OP_RETURN of at least 100 bytes:
Result: 2 NST (1 sat above minimum, within the 2-to-1 issuance window).
Sending a transaction on Block 911,000, sending 5000 sats with an OP_RETURN of at least 100 bytes:
Result: 3000 NST (5000 - 2000, after the 2-to-1 issuance period).

Detailed Example:

At block height 899,999, sending 3000 sats:
Result: (3000 - 2000) * 2 = 2000 NST
Sending to: bc1pm0ther3jqnjz4n7342djtvkgq3rsu2g6qdr5wgkgm4slyvt343fsrg8p4w
Amount: 3000 sats  
OP_RETURN payload:
bc1pns0rtmeplsxxx_example_xxxxxxx hop hop hop hop hop hop hop hop hop hop hop hop hop hop hop hop hop

Below is an example illustrating a potential misuse. This tribute transaction follows all the rules, while technically allowed, it is doing something weird and embedding a nested meta-protocol within the issuance transaction. This is strongly discouraged. Such practices may be considered spam and could lead to transactions being filtered, delayed and more costs.
If this user confirmed this transaction in block 899,999 as well:
Result: (4500-2000) * 2 = 5000 NST
Sending to: bc1pm0ther3jqnjz4n7342djtvkgq3rsu2g6qdr5wgkgm4slyvt343fsrg8p4w
Amount: 4500 sats
OP_RETURN payload:
1LeapFrogABC123xxxxxxxxxxxxxxxxxxx {"hop_return":v1, "type":"fencehopper", "from":"1LeapFrogABC123xxxxxxxxxxxxxxxxxxx", "to":"1JumpManXYZ789xxxxxxxxxxxxxxxxx", "note":"Frog tokens 500_000"}

Transacting NST, Hop-Return Protocol

Unlike the issuance, NST uses the Hop-Return Protocol for transfers. This is not a UTXO-based system; rather, it is a meta-account-based system. The Hop-Return Protocol employs meta-accounting through hop-returns, or OP_RETURNs that contain specific json data. We firmly believe this is clearly superior to conventional methods, though admittedly citation needed. Transactions between Hop-Return enjoyers must strictly adhere to the JSON format below within the OP_RETURN payload to ensure NSTs don't become spam on the Bitcoin blockchain.
Hop-Return transfer payloads examples:

{
  "version": "1",
  "to": "bc1pxxxx_example_addr_xxxxx",
  "amount": "69",
  "type": "transfer",
  "message": "optional note"
}
Another Example
{"version": "1", "to": "bc1pxxxx_example_addr_xxxxx", "amount": "all", "type": "transfer", "message": "optional note"}
The reason for making the amount value a string is to give flexibility with the "all" syntax.
valid values for amount are positive integers and the keyword "all".
Currently the only Hop-Return transaction type is a "transfer".
A sender's address, with NST associated to it, must be present in the input of the transaction.
Destination address, the to field, can be any valid bitcoin address.
amount must reflect the valid amount of remaining funds, based on the aggregate values of the input addresses. FIFO used if multiple inputs are specified that contain NST.
The payload must consist solely of a UTF-8 encoded JSON message.
FIFO example with multiple addresses and outputs:

This example presents a complex yet valid Hop-Return transaction. It includes two inputs and three outputs, with each OP_RETURN output targeting a different address.
Inputs:

- index 0 input bc1q45spausz4ghvwg36hk63ttn6xj0ksuze9xc9cm has a total of 20,000 NST
- index 1 input 3K9Vsm81ZgqqkQ9jPVcucrTi26zbV5zMHw has a total of 70,000 NST

Output:

- index 0 <a change address>
- index 1 OP_RETURN:
  {
    "version": "1",
    "to": "16RkcHAPsNtU6i4sT6siiLK5pTwoHLmhnk",
    "amount": "30000",
    "type": "transfer",
    "message": "Thanks for lunch, glad to be making a finanical transaction with NST!"
  }
- index 2 OP_RETURN
  {
    "version": "1",
    "to": "bc1prnr72gav7c94ng6xxgyjlmq63ddp0ccevujgca3vjzln0ad8w54s80lu8g",
    "amount": "500",
    "type": "transfer",
    "message": ""
  }

This would result in:

bc1q45spausz4ghvwg36hk63ttn6xj0ksuze9xc9cm having zero NST
3K9Vsm81ZgqqkQ9jPVcucrTi26zbV5zMHw having 59,500 NST
16RkcHAPsNtU6i4sT6siiLK5pTwoHLmhnk having 30,000 additional NST
bc1prnr72gav7c94ng6xxgyjlmq63ddp0ccevujgca3vjzln0ad8w54s80lu8g having 500 additional NST.

If instead bc1prnr72gav7c94ng6xxgyjlmq63ddp0ccevujgca3vjzln0ad8w54s80lu8g was receving "all" instead of "500", the total amount sent would have been the rest of the funds in the inputs (60,000).
There can only be one "all" specfied in a Hop-Return amount field within a single transaction.
Filter Hopping

Given the natural alignment between NST and NOSTR⁴, the two protocols complement each other effectively. Should services begin filtering NSTs or Hop-Return transactions, the community can leverage an interesting mechanic with NOSTR ("Notes and Other Stuff Transmitted by Relays") to dynamically distribute raw hex transactions. Ideally, NOSTR would serve as an open, public broadcasting layer for NST transaction data, enabling miners to fairly and transparently compete when assembling new blocks. Until Bitcoin's mempool policies natively accommodate such transactions, NOSTR acts as a practical stopgap, supporting decentralization and fairness within the mining ecosystem.
Conclusion

The Hop-Return Protocol and NSTs represent an innovative exploration of Bitcoinâ��s underutilized OP_RETURN capabilities. By intentionally leveraging Bitcoin's restrictive relay rules as strengths rather than limitations, NSTs create a unique tokenization model built on social consensus, non-standard transactions, and clever meta-protocol designs. This playful yet earnest approach highlights new possibilities for on-chain experimentation, reinforcing Bitcoinâ��s ethos of decentralization and permissionless innovation. As the Bitcoin community continues to evolve, there will be further investigation into creative ways to utilize Bitcoinâ��s protocol limits, inviting developers, miners, and enthusiasts to rethink what might be achievable on-chain.
Preemptive FAQ

Q: What will the funds in the MOAT be used for?
A: Funds in the MOAT are intended to support the creation of additional large OP_RETURN blocks. This serves both as a way to secure the network, by generating meaningful fees for miners, and to honor the vision behind the MOAT. Funds will primarily be used in low fee environments. If for whatever reason the MOAT balance grows significantly, the community should reasonably expect that lambos might be acquired and developers supported.
Q: What will happen when large OP_RETURNs become standard for relay policy?
A: This project will lose its charm.
Q: How will we know if the protocol or rules have changed?
A: Future OP_RETURNs from the MOAT address bc1pm0ther3jqnjz4n7342djtvkgq3rsu2g6qdr5wgkgm4slyvt343fsrg8p4w will serve as the authoritative source of protocol amendments. Version numbers will help discern between previous and updated NST rules, which might not be backward-compatible.
Q: Is there a recommended tool or wallet to construct these OP_RETURN transactions?
A: As of launch, no official wallet exists; however, you're free to construct your own. Likely wallet support will be created depending on tribute levels.
Q: Can I use more than one address in my OP_RETURN payload when tributing to the MOAT?
A: No. MOAT demands clarity. Exactly one Bitcoin address followed by a space is required. Additional addresses might confuse the Mother, causing your tribute to be ignored. See above for details.
Q: Is there a maximum limit on how many NST tokens I can receive?
A: No, the generosity of your tribute directly translates into tokens given the above formulas. Treat every tribute to the MOAT address as a donation.
Q: Can I lose my NST tokens if I make a mistake in my OP_RETURN payload?
A: No. Any invalid or incorrectly formatted OP_RETURN payload will be considered null and void and will not result in token loss or transfers.
Q: Can I retract or reverse a tribute transaction once sent?
A: No. Tributes to MOAT are irreversibleâ��consider it a digital leap of faith.
Q: Am I guaranteed to receive NST if I send tribute to MOAT?
A: Yes, the meta-protocol enforces it automatically.
Q: Is UTF-8 specifically required for encoding OP_RETURNs?
A: Yes.
Q: Should I tribute to the MOAT?
A: No, but some may disagree.
Q: Do NST tokens have monetary value?
A: No, but some may disagree.
Q: Can my OP_RETURN message for transfers be less humorous and more serious?
A: Serious messages inside of transfers are technically acceptable; however, consistently low-quality or inappropriate payloads might prompt the community to implement filtering rules. Please keep your messages aligned with the project's vision, and always meet the minimum byte requirement, at least 100 bytes.
References

Footnotes


Marathon Digital Holdings' Slipstream https://slipstream.mara.com ↩ ↩²


Ordinals Protocol Documentation. https://docs.ordinals.com ↩


Counterparty Protocol. https://www.counterparty.io/ ↩


Nostr Protocol Documentation. https://nostr.com ↩
No results found