# dHouse Topic Manager (`tm_dhouse`)

Admits outputs whose locking script is a **dHouse covenant lock** — the
on-chain state machine of the dHouse protocol on BSV mainnet.

## Lock structure

Every dHouse lock is a push-tagged **prefix** (each field: one length byte in
`[1, 75]` followed by exactly that many raw bytes) followed by a
class-specific script **suffix**. A script is admitted iff:

1. every field's length byte equals the class layout's expected length
   exactly,
2. the GID field equals `"DHOUSE" ‖ CLASS ‖ 0x01`, and
3. the script is strictly longer than the prefix (suffix present).

## Classes

| Class   | GID byte | Prefix bytes | Fields |
|---------|----------|--------------|--------|
| table   | `T`      | 310          | 22     |
| hand    | `H`      | 311          | 21     |
| receipt | `R`      | 68           | 4      |
| purse   | `P`      | 120          | 7      |
| vault   | `V`      | 158          | 10     |

All numbers are little-endian. `TABLE_ID = table GID(8) ‖ SID(8 LE)` —
16 bytes, shared by table, hand, and receipt locks.

## Admission rules

- Every output that parses as any dHouse class is admitted.
- **All previous coins are retained** — the table chain's ancestry is the
  audit trail and must never be garbage-collected.
- A transaction with no dHouse outputs *and* no previous dHouse coins is
  rejected (`NoAdmissibleOutputs`).

No signature verification is performed at admission: the covenant suffix
enforces spend rules on-chain.