Glasshouse: adversarial disclosure for tokenized-equity venues

01 Overview

A tokenized-equity venue holds three things a researcher can break: the matching and custody rails that move positions, the collateral logic that keeps a token backed, and the bridge surface that connects the venue to the chains it settles on. A finding against any of these is worth money to whoever holds it, and the current disclosure path routes that finding directly to the one party with an incentive to suppress it.

Glasshouse restructures that path. A finding enters under seal, is verified by a staked panel that cannot include the disclosed venue, and resolves on a market whose outcome is determined by the attestation certificate rather than by any statement the venue makes.

1.1 Disclosure asymmetry

Coordinated disclosure assumes the receiving party wants the finding fixed. That assumption holds for most software vendors and fails for a venue whose unpatched exploit is economically useful to insiders, or whose disclosure would be materially adverse. The failure modes are ordinary:

• Silent expiry. The report is received, never acknowledged, never patched. The researcher has no recourse that does not involve publishing an unpatched exploit.
• Reward capture. The venue defines both the severity and the payout, after it already holds the finding.
• Selective remediation. The vulnerability is quietly patched and the disclosure is never published, so the market never learns the venue was exposed.

In each case the venue is simultaneously the accused, the judge, and the paymaster. Glasshouse separates those three roles into three parties with independent incentives.

1.2 Design goals

1.3 Non-goals

• Glasshouse does not assess individual tokenized securities, issuers, or their underlying equities. The scanned surface is venue infrastructure only.
• Glasshouse is not a replacement for a pre-deployment audit. It operates against systems already carrying live value.
• The protocol does not execute, prove, or reproduce exploits against production systems. Verification operates on forked state.

02 System architecture

Seven components. Three run on-chain as contracts, three are off-chain services with on-chain anchoring, and one is a client library distributed to agent operators.

2.1 Components

2.2 Trust boundaries

The gateway is trusted for availability but not for integrity: it never holds plaintext it can read alone, and every accepted submission is anchored by a commitment the filer can prove independently. The panel is trusted for correctness under an honest-majority assumption bounded by t of n attestors. Contracts are trusted for execution and hold all custody.

03 Claim lifecycle

A claim is the protocol’s unit of work. It carries a commitment, a sealed payload, a target venue, a bond reference and — after quorum — a certificate. Claims move through a strictly ordered state machine; no transition is reversible except DISPUTED, which re-enters review once.

3.1 States

3.2 Transition rules

// transition guards, evaluated in gh-registry
SEALED   → TRIAGE    requires bond.locked && commitment.anchored
TRIAGE   → ATTESTED  requires |sig| ≥ t && recusal.clean && severity.agreed
TRIAGE   → REJECTED  requires |sig| < t at review.deadline
ATTESTED → WINDOW    auto, deadline = now + window(severity)
WINDOW   → DISCLOSED on patchProof.verified or block.timestamp > deadline
DISCLOSED→ SETTLED   on tradingPeriod.elapsed && !dispute.raised
DISCLOSED→ DISPUTED  on challengeBond.posted within challengeWindow
DISPUTED → SETTLED   on secondReview.final   // no further appeal

04 Sealed ingress

Ingress must satisfy two properties that pull against each other: the protocol has to prove a specific finding existed at a specific time, and no party may be able to read it until the panel is assembled. The first is solved by commitment, the second by threshold encryption.

4.1 Envelope format

// submitted to gh-gateway; only `header` is ever readable pre-quorum
{
  "header": {
    "venue":        "gh:venue:<registry-id>",
    "surface":      "custody" | "matching" | "collateral" | "bridge",
    "claimedSev":   "S0" | "S1" | "S2" | "S3",
    "agent":        "gh:agent:<pubkey-hash>",
    "nonce":        "<uint64>",
    "submittedAt":  "<unix-seconds>"
  },
  "commitment":   "keccak256(payload ‖ salt)",
  "payload":      "<threshold-encrypted blob>",
  "encScheme":    "tpke-bls12381-g1",
  "sig":          "<agent signature over header ‖ commitment>"
}

The header is deliberately coarse. It carries enough for routing, recusal and rate limiting, and not enough to identify the vulnerability class. claimedSev is the filer’s assertion and carries no weight at settlement; the panel assigns the binding severity.

4.2 Commit–reveal

1. The agent computes C = keccak256(payload ‖ salt) and encrypts payload to the current panel epoch public key.
2. The gateway anchors C, the header and the agent signature on-chain. The anchoring transaction establishes priority: the earliest anchored commitment for a colliding finding is the one that pays.
3. At quorum formation, t attestors each contribute a decryption share. Reconstruction happens in the attestor client, never at the gateway.
4. At disclosure, salt is published, so any observer can recompute C and confirm the published finding is byte-identical to the one committed before review.

05 Attestation layer

Attestation replaces the venue as arbiter. An attestor is an address with stake locked in gh-vault, a published identity commitment, and a disclosed affiliation set used for recusal.

5.1 Quorum and certificates

Each claim draws a panel of n attestors by verifiable random selection seeded on the anchoring block hash, filtered by the recusal predicate. A certificate is valid when at least t partial BLS signatures over the same (claimId, verdict, severity, payloadHash) tuple aggregate successfully.

// aggregate verification, executed on-chain
function verify(
    bytes32 claimId,
    uint8   verdict,        // 0 = reject, 1 = affirm
    uint8   severity,
    bytes32 payloadHash,
    bytes   aggSig,
    uint256 signerBitmap
) returns (bool) {
    require(popcount(signerBitmap) ≥ threshold);
    require(noRecusalViolation(claimId, signerBitmap));
    return blsVerify(aggregateKeys(signerBitmap),
                     digest(claimId, verdict, severity, payloadHash),
                     aggSig);
}

Severity is agreed by median of submitted values among affirming signers, not by unanimity. A signer whose severity deviates by more than one band from the median is recorded; repeated deviation reduces selection weight.

5.2 Severity taxonomy

Generic vulnerability scoring maps poorly onto venue infrastructure, where the meaningful axis is value at risk rather than exploit complexity. Glasshouse uses four bands.

5.3 Recusal rules

An attestor is excluded from a panel when any of the following holds. Violation is slashable, and detection is retrospective — affiliations are published as commitments and revealed on challenge.

• The attestor’s disclosed affiliation set intersects the target venue’s operator set.
• The attestor operates, or shares an operator with, the filing agent.
• The attestor holds an open position on the claim, or on any claim against the same venue in DISCLOSED.
• The attestor was slashed within the preceding cooldown period.

06 Remediation window

On attestation the venue receives the finding and a deadline derived from severity. The window is the only period in which the protocol withholds information from the public, and it is bounded on both ends.

• Acknowledgement. The venue may acknowledge, which is recorded but grants no extension. Silence is not a veto and does not pause the clock.
• Patch proof. The venue submits a proof of remediation — a deployment reference plus a sandbox re-run that fails to reproduce. Acceptance moves the claim to DISCLOSED immediately, with remediation noted.
• Expiry. At deadline, disclosure publishes regardless of venue state. There is no extension mechanism and no administrative override.

A venue with a coverage bond may request one extension per claim, capped at the original window, which is drawn against that bond. This is the only cooperation-linked concession in the protocol and it costs the venue capital rather than time granted for free.

07 Market engine

The market prices one proposition: this finding, as disclosed, is a genuine vulnerability of the attested severity against the named venue. It opens only on disclosure and resolves from the certificate.

7.1 Pool mechanics

Positions are parimutuel rather than order-book. A pool avoids the thin-book failure mode that would otherwise let a well-capitalized venue set the price on its own claim, and makes settlement a division rather than a matching problem.

// settlement, YES resolution
poolTotal   = yesStake + noStake
protocolFee = poolTotal × feeRate
distributable = poolTotal − protocolFee

filerShare  = distributable × filerRate × severityWeight
winnerPool  = distributable − filerShare

for each position p in YES:
    payout(p) = winnerPool × (p.stake / yesStake)

The filer’s share scales with attested severity, not with claimed severity or pool size alone. A trivial finding that attracts speculative volume does not pay out like a custody break.

7.2 Settlement

Settlement is a pure function of on-chain state: the certificate, the position ledger and the parameter set at the block the claim was disclosed. Any observer can recompute every payout from public events. Parameters are pinned per-claim at disclosure so a governance change cannot retroactively alter an open market.

08 Collateral and slashing

Three distinct bonds, held by gh-vault, each answering a different failure.

Slashed filer bonds do not accrue to the venue under any condition. Routing them to the accused would create a direct incentive to influence rejection. Destination is one of treasury, attestor reward pool, or burn — see §13.

A venue with no coverage bond is not exempt from claims. It is recorded in the registry as coverage: none, which the indexer exposes as a public field. Non-participation is a disclosure, not an escape.

09 Agent interface

Agents are autonomous scanners registered by an operator who posts bond on their behalf. The protocol is indifferent to whether an agent is a model, a fuzzing harness, a static analyzer or a person driving the SDK by hand; it verifies findings, not authorship.

9.1 SDK surface

// gh-agent-sdk, operator-side
const agent = await Glasshouse.register({
  operator:  wallet,
  bond:      parseUnits("...", 6),
  surfaces:  ["custody", "collateral"],
});

agent.on("venue:registered", async (venue) => {
  const findings = await scan(venue.surfaces);
  for (const f of findings) {
    await agent.submit({
      venue:      venue.id,
      surface:    f.surface,
      claimedSev: f.severity,
      payload:    f.report,        // sealed client-side before transit
    });
  }
});

agent.on("claim:attested", (c) => log(c.id, c.severity, c.window));
agent.on("claim:settled",  (c) => log(c.id, c.payout));

9.2 Reputation

Each agent carries a rolling record: submissions, affirmation rate, median attested severity, and slashing history. Reputation is not a score the protocol trusts — it does not gate settlement — but it drives two mechanisms:

• Bond scaling. Required filerBond is a function of recent affirmation rate. A consistently accurate agent posts less capital per claim.
• Ingress priority. Under gateway congestion, submissions are ordered by reputation before timestamp, bounded so a new agent cannot be starved indefinitely.

An operator whose agent is rejected repeatedly enters a cooldown during which the agent cannot file. The cooldown is per-agent, not per-operator, and does not transfer on re-registration — identity is bound to the operator’s bonded address.

10 Threat model

11 Parameters

Protocol constants and their intended calibration. Values marked provisional are targets for testnet calibration, not commitments; they are pinned per-claim at disclosure once set.

12 Roadmap

Sequenced by dependency rather than date. Each phase closes on a capability, and no phase that touches live value ships before the phase that verifies it.

13 Open problems

Recorded rather than deferred quietly. Each blocks a parameter freeze, not the architecture.

14 Glossary