Ostiary: Accountable Gatekeepers for Every Chain

Whitepaper, draft v0.1 · 30 October 2026

Abstract

Ostiary is a network of accountable gatekeepers for digital assets. Every withdrawal from a protected wallet needs the network's co-signature, and the network checks it against public house rules first. An operator who co-signs a forbidden withdrawal loses their stake to the victim.

The network signs through key sharing (threshold signatures). That makes it work on any chain with common signature schemes, including chains without programmable wallets: Bitcoin, Tron, Substrate chains such as Enjin, and plain Ethereum accounts without a smart contract. Those are exactly the places where today there is neither automatic protection nor liability.

The OSTR token is the gatekeepers' bond. Customers pay premiums in stablecoins, operators earn from them and are liable with their OSTR. The more value Ostiary guards, the more OSTR has to be locked.

The name comes from the Latin ostiarius, the doorkeeper. He opens the door only to those who may enter, and he answers for it.

1. The problem: the approval is the weak point

The largest losses of 2025 and 2026 did not come from programming bugs. They came from signatures that were formally valid: compromised signing systems, spoofed interfaces, pre-signed transactions. Each time, the code did exactly what the signature asked for.

The pattern is clear. Whoever controls the signature controls the money, and no party other than the victim is liable for it. Nexus Mutual, the largest on-chain insurer, typically excludes signer compromise because operational security cannot be verified.

The Binance figures come from analysts on the day after the incident. Binance has not confirmed cause or size. The case serves here as an illustration, not as evidence.

2. Why existing solutions fall short

There are three kinds of protection, and each has a gap that Ostiary closes.

This defines the positioning. Where a wallet contract can enforce the rules itself, nobody needs Ostiary, and we say so. Ostiary is for everything else: accounts that only know a single signature. That covers most hot wallets of exchanges, custodians and agents.

The difference in one sentence: Ostiary makes a risk that could not be verified verifiable, and therefore insurable.

3. The protocol

A withdrawal goes through five steps. Each step leaves evidence, so at the end it is possible to say exactly who approved what.

1. Shared key. The customer generates a key together with the network without any party ever knowing it in full. The customer holds one share, the network holds the remaining shares spread across several operators (for example 2 of 3 on the customer side, with the network as a mandatory share that is internally 5 of 7). The chain sees an ordinary signature.
2. House rules. The customer defines a policy and writes its hash to the Ostiary registry. Examples: daily limit per asset, recipient allowlist, no delegatecall outside an allowlist, no EIP-7702 delegation, no change of admin rights. Any policy change only takes effect after a delay that is longer than any action it protects.
3. Independent verification. Every operator decodes the raw transaction itself and simulates it against current chain state. Each chain has at least two independently written decoders, and every operator uses its own data sources. An interface, as in the Bybit case, cannot fool the network because the network reads no interface.
4. Attestation. An operator who approves signs a statement with their personal operator key: this raw transaction, checked against this policy, result allowed. Only then do they take part in the joint signature. Statements are batched and periodically anchored as a Merkle root on the settlement chain.
5. Liability. If a transaction that violates the policy appears, anyone can submit a violation proof. It consists of the raw transaction, the policy and the attestations. The operators who approved lose their stake, and the victim is compensated from it.

1. 1. Customer requests a withdrawal
2. 2. Two decoders, one simulation
3. 3. Rules satisfied? If not: blocked, customer notified
4. 4. Personal attestation
5. 5. Joint signature
6. Only on misapproval: violation proof with attestation, stake goes to the victim

The attestation solves the attribution problem of threshold signatures. A joint signature does not reveal who took part, but the personal statements do. An operator who co-signs without a statement violates the protocol and is slashed as well.

If the network fails, every wallet has an emergency exit. Where the chain allows it (Bitcoin Taproot with a timelock, Substrate proxy with a delay), the customer can control their funds alone after a long waiting period. On other chains the network share is transferred via resharing to a replacement the customer names.

4. Coverage model: how much liability is really behind it

Ostiary covers a fixed amount per wallet, not the entire balance. Coverage is always backed by stake that can actually be seized when it matters.

A withdrawal needs approval from k of the n operators in a wallet's committee. In the worst case exactly the k operators with the smallest stake approve a forbidden transaction. Their stake has to cover the loss after a haircut for token price swings:

Here S(i) is the i-th smallest stake in the committee and h is the haircut (initial value 0.5). If the OSTR price falls, the maximum coverage falls automatically, and either customers are notified or operators have to top up.

Compensation comes from three layers, in this order:

Worked example. A custodian holds USD 20 m in a hot wallet and wants USD 10 m covered. With k = 5 and h = 0.5, the five smallest stakes together have to be worth USD 20 m in OSTR, so at least USD 4 m each. At a 2 % annual premium the customer pays USD 200,000 per year.

This implies an honest limit. No stake network can cover a loss the size of Binance's, and Ostiary does not promise it. The model fits hot wallets up to the tens of millions. We recommend that customers regularly move larger balances to cold storage, and that step is itself a policy rule.

5. Cryptography and chain coverage

For each chain Ostiary needs two things: a threshold scheme for its signature type and a dedicated decoder for its transaction format. The chain itself does not need to know about any of it, and nobody has to ask for permission.

One caveat applies to Substrate. Threshold schemes for sr25519, the default for many Substrate accounts, are less mature. Ostiary wallets on Substrate therefore use Ed25519 or ECDSA accounts. Which account types and pallets Enjin supports in practice will be checked against the live runtime before phase 3.

Settlement, meaning the registry, stakes, attestation roots and violation proofs, runs on an existing Ethereum L2 (see ADR-0001). A dedicated chain would need its own validators and its own security, and would therefore be exactly the kind of risk Ostiary exists to reduce.

Violation proofs are checked in two stages. First optimistically: a proof is submitted, and operators have a window to dispute it. If disputed, a ZK proof decides: the reference decoder and the policy evaluator run inside a zkVM that proves the raw transaction violates the policy. That lets a contract on Ethereum rule on a Bitcoin or Substrate transaction without understanding its format itself.

6. Security model and honest limits

Ostiary is infrastructure itself, and infrastructure is exactly what was attacked in 2025 and 2026. The design assumes that individual operators will be compromised.

What Ostiary does not do is written into every customer contract:

• Rule-compliant attacks are not covered. A withdrawal to an allowed address within the limit goes through, even if it is malicious.
• Bugs in the token or the chain are not covered. Ostiary protects wallets, not a token's code and not a chain's consensus.
• Compromise of the customer share alone causes no loss as long as the network enforces the rules. That is the whole point.
• Coverage is capped (section 4). Ostiary is liability for misapprovals, not all-risk insurance.

At the start, the founding team runs a large share of the nodes itself. That is centralised, and we say so openly. The roadmap (section 11) defines when external operators take the majority.

7. Tokenomics

There are exactly 1,000,000,000 OSTR, fixed, with no later inflation. The token's value depends on one quantity: how much value Ostiary guards. More guarded value requires more locked stake and generates more premiums, part of which flow into buybacks.

Allocation

Where premiums go

• 70 % to operators, in stablecoins. Real yield from real revenue, not from newly minted tokens.
• 20 % to the protocol, used to buy back OSTR on the market and burn it.
• 10 % to the reserve (layer 2 of the coverage model).

Slashed OSTR is not handed to the victim as tokens. It is auctioned and the victim receives stablecoins. That way nobody has to accept a token whose price is falling at the moment of a loss.

Does it pay for operators?

An operator's yield on stake depends on premium rate p, haircut h, committee k of n, and the factor r by which one stake backs several wallets at once:

With p = 4 %, h = 0.5 (initial value from section 4), k = 5, n = 7 and r = 3 this gives about 3 % per year in stablecoins, plus operator incentives in OSTR. Without multi-backing (r = 1) it would only be 1 %. If h rises to 0.75 after a probation period, yield rises to about 4.5 %. Multi-backing is standard practice for insurers but carries concentration risk: a compromised operator could misapprove several wallets at once. Therefore r is capped at 3, and wallets in the same committee may not share operators running the same software.

These assumptions are starting values. Premium rates and haircuts will be calibrated with the first customers and are explicitly provisional.

8. Business model and monetisation

Ostiary makes money before there is a token. The token comes once paying customers exist, because then it tells a real story instead of a promise.

The policy audit is the entry point. It uses exactly what the founding team already does: review wallet setups, replay past hacks, write rules. Every audit customer is a potential Guard customer, and every policy written becomes part of a growing rule library.

Scenario, not a forecast

In the first years the founding team runs a large share of the nodes itself and also receives the operator share of premiums for them. The biggest lever for the founders, however, is the team's token allocation. It is only worth something if the network is actually used.

All figures are orientation assumptions. Whether customers pay these prices is what the first ten customer conversations will establish (section 11).

9. How we build it

Ostiary has three parts: the signer node every operator runs, the settlement contracts on an L2, and the customer SDK. Almost everything is built from vetted open-source components. Original code is mainly the decoders, the policy engine and the liability logic.

Three rules apply to the code. First, every component that moves money is externally audited before mainnet. Second, every decoder implementation gets a public bug bounty from the treasury. Third, every known hack that involves a signature is replayed as a test case: Bybit, Drift and the Ethereum part of Binance are in the test suite.

With AI agents most of this can be built by a small team. The MPC cryptography itself is not rewritten but taken from audited libraries. Which of them meet licensing and audit requirements for production is checked in phase 1.

10. How we operate it

At the start, seven signer nodes run at no fewer than three providers in three countries. No provider holds enough nodes to produce a signature on its own.

Infrastructure in phase 1

Altogether roughly EUR 500 to 1,500 per month. These are estimates and depend on providers and chains.

Protecting key shares

A VPS provider can in principle look into its machines' memory. Three things follow. Key shares are only stored encrypted on disk and, where the provider offers it, inside a confidential VM. Shares are refreshed regularly (proactive resharing), so stolen old shares become worthless. And phase 1 runs only on testnet and small coverage until the infrastructure has proven itself.

Day-to-day operation

• Round-the-clock monitoring: every node reports health, disagreements between decoders and disagreements between data sources. Any disagreement blocks signing and raises an alert.
• On-call: initially the founding team, later spread across operators. An alert must be acknowledged within 15 minutes.
• Emergency brake: on suspicion of compromise the network can pause co-signing for all wallets. The brake can only stop, never move funds.
• Post-mortem: every incident is written up publicly within 72 hours.

External operators from phase 3

Prospective operators need a minimum stake and their own infrastructure, and during a probation period they only join committees with small coverage. Committees are mixed so that each contains several providers, countries and decoder implementations. The goal is that after 24 months the founding team no longer holds a blocking minority in any committee.

11. Roadmap

Each phase only starts once the gate before it is met.

The gates are hard conditions. If one is not met, the next phase does not start; the concept is adjusted or ended instead.

12. Prior art and differentiation

The individual building blocks of Ostiary already exist. What is new is their combination: threshold signatures on any chain, personally attributable approvals, multiply implemented decoders, and a stake that goes to the victim on misapproval.

The window is short. Newton could introduce redistribution to victims relatively quickly. Ostiary therefore bets on what is hard to copy: support for chains without smart contracts, a rule library built from real audits, and a test suite of replayed hacks.

This table reflects 30 October 2026. Competitor information comes largely from their own material and will be verified directly in phase 0.

13. Risks and open questions

Four risks can end the project. Each is checked before the next roadmap gate.

Legal questions are deliberately out of scope here. A product that is liable for losses in exchange for a premium may count as insurance, and the token may be classified as a financial instrument. Both must be clarified with specialist lawyers before the token launch in phase 3.

Open technical questions:

• Which threshold libraries meet licensing and audit requirements for production?
• How expensive is a ZK violation proof for a complex transaction today?
• Which account types does the current Enjin runtime support, and can a delayed proxy serve as the emergency exit there?
• How high must premiums be for operators to stay profitable without token incentives?

Sources

As of 30 October 2026. The incident analyses partly rely on secondary sources because some original post-mortems were not directly accessible. The full analysis is in research-hack-analysis-de.md (German).

• Binance: The Block, Cryptoticker, EIP-7702
• KelpDAO: CoinDesk, The Defiant, DeFiPrime
• Drift: BlockSec, Nexus Mutual incident report, CoinDesk
• Bybit: NCC Group, The Block, Safe Guards
• Substrate: Parity, building a hot wallet with Substrate primitives
• Competitors: see the table in section 12