declare const _default: "# SHIP Topic Manager\n\n**Protocol Name**: SHIP (Service Host Interconnect Protocol)  \n**Manager Name**: `SHIPTopicManager`  \n\n---\n\n## Overview\n\nThe SHIP Topic Manager is responsible for identifying _admissible outputs_ in transactions that declare themselves as part of the SHIP protocol. In other words, it looks at transaction outputs (UTXOs) that embed certain metadata via a [PushDrop](https://www.npmjs.com/package/@bsv/sdk#pushdrop) locking script. This metadata must meet SHIP-specific requirements so that your node or application can recognize valid SHIP advertisements.\n\nA **SHIP token** (in the context of BRC-101 overlays) is a UTXO containing information that advertises a node or host providing some topic-based service to the network. That topic must be prefixed with `tm_` \u2014 short for \"topic manager.\"\n\n---\n\n## Purpose\n\n- **Announce**: The SHIP token is used to signal that \"this identity key is hosting a certain topic (prefixed with `tm_`).\"\n- **Connect**: By publishing a SHIP output, a node indicates it offers some service or is a participant in a specific overlay \"topic.\"\n- **Authorize**: The SHIP token includes a signature which binds it to an identity key, ensuring authenticity and preventing impersonation.\n\nThis allows other nodes to discover hosts by querying the lookup service for valid SHIP tokens.\n\n---\n\n## Requirements for a Valid SHIP Output\n\n1. **PushDrop Fields**: Exactly five fields must be present:\n   1. `\"SHIP\"` \u2014 The protocol identifier string.\n   2. `identityKey` \u2014 The 33-byte compressed DER secp256k1 public key that claims to own this UTXO.\n   3. `advertisedURI` \u2014 A URI string describing how or where to connect (see BRC-101).\n   4. `topic` \u2014 A string that identifies the topic. Must:\n      - Start with `tm_`\n      - Pass the BRC-87 checks\n   5. `signature` \u2014 A valid signature (in DER) proving that `identityKey` is authorizing this output, in conjunction with the PushDrop locking key.\n\n2. **Signature Verification**:  \n   - The signature in the last field must be valid for the data in the first 4 fields.\n   - It must match the identity key, which in turn must match the locking public key used in the output script.  \n   - See the code in `isTokenSignatureCorrectlyLinked` for the implementation details.\n\n3. **Advertised URI**:  \n   - Must align with what is contemplated in BRC-101, which enforces certain URI formats (e.g., `https://`, `wss://`, or custom prefixed `https+bsvauth...` URIs).\n   - No `localhost` or invalid URIs allowed.\n\nIf any of these checks fail, the SHIP token output is _not_ admitted by the topic manager.\n\n---\n\n## Gotchas and Tips\n\n- **Field Ordering**: The fields **must** appear in the exact order specified above (SHIP -> identityKey -> advertisedURI -> topic -> signature).\n- **Exact Five Fields**: More or fewer fields will cause the manager to skip the output.\n- **Proper Locking Script**: Ensure the output is locked with a valid [PushDrop](https://www.npmjs.com/package/@bsv/sdk#pushdrop) format. If the `lockingScript` can\u2019t be decoded by `PushDrop`, the output is invalid.\n- **Signature Data**: The signature is a raw ECDSA signature over the raw bytes of the preceding fields. The manager expects that the identity key and signature match up with the logic in `isTokenSignatureCorrectlyLinked`.\n- **Funding**: Remember to fund your SHIP output with at least one satoshi so it remains unspent if you want your advertisement to be valid.\n";
export default _default;
//# sourceMappingURL=SHIPTopic.docs.d.ts.map