# Key Features

## 1. Privacy-First Bounty Payouts

Tirai lets project treasuries pay bug bounties through the **Cloak Shield Pool**, severing the on-chain link between the payer and the recipient.

<figure><img src="/files/Xankh6DtOSfVDzlpewMg" alt="" width="563"><figcaption></figcaption></figure>

Key characteristics:

* Project signs **one deposit** into the shielded pool
* Researcher claims with a **separate, unlinkable withdrawal** transaction
* A public observer sees **two unrelated transactions** to and from the pool — no edge between Wallet A and Wallet B

This protects researchers from doxxing while keeping the payment fully on-chain and verifiable.

## 2. Off-Chain Claim Tickets

When the project deposits, the Cloak SDK returns a **claim ticket** — an opaque base58 blob containing the UTXO commitment plus its spending key.

<figure><img src="/files/OR7MYv8Cq6UVeFbvb8WK" alt="" width="563"><figcaption></figcaption></figure>

Tirai surfaces the ticket in three forms:

* **Copy-paste blob** for direct messaging
* **QR code** for mobile handoff
* **Pre-formatted Telegram message** templated to the researcher's contact handle

The ticket is **never persisted** by Tirai — not to a database, not to a backend, not to local storage past the success card.

## 3. Fresh-Wallet Recipient Mode

Researchers can claim to either their existing wallet or a **brand-new keypair generated inside the browser** — defeating off-chain de-anonymization vectors.

<figure><img src="/files/O6REwWC1ynyTSxNqao3g" alt="" width="563"><figcaption></figcaption></figure>

Destination options:

* **Existing wallet** — the connected Phantom or Solflare adapter
* **Fresh wallet** — a brand-new keypair with a non-dismissible save-key dialog blocking the claim until the secret is stored

Fresh-wallet mode produces an address with **zero on-chain history**, making it the maximum-privacy default for whitehats who need full unlinkability.

## 4. Viewing-Key Scoped Audit

Cloak issues a **per-deposit viewing key** that the project shares with their auditor off-chain.

<figure><img src="/files/OTqNl0B8fLR64OgrXVXY" alt="" width="563"><figcaption></figcaption></figure>

The auditor sees:

* Every payment the project ever made via Tirai
* Amount, date, label, and claim status for each entry
* A full ledger sufficient for compliance filing

What the auditor cannot see is the **destination wallet** of any claim — that field is structurally absent from the SDK output, not hidden by a flag.

## 5. Non-Custodial Architecture

Tirai deploys **no Solana program** and operates **no payment backend**.

Architectural properties:

* Funds settle directly inside the **Cloak Shield Pool**, owned by the Cloak team
* Tirai holds **no user funds**, ever
* Bounty board metadata lives in Supabase; payments never touch it
* Even if Tirai's frontend goes offline, deposits and claims remain provable via the SDK

This guarantees that **protocol rules — not Tirai — determine payouts**.

## 6. Public Bounty Board

Tirai ships an **optional bounty matching layer** that lets projects post bounties publicly and accept applications from researchers.

<figure><img src="/files/CDB6Ql3spZmpcHU6Rjj3" alt="" width="563"><figcaption></figcaption></figure>

Bounty board features:

* Projects post bounties publicly with reward, deadline, and eligibility
* Researchers apply with a contact handle such as Telegram or Discord
* On acceptance, the UI auto-redirects to the payment page with the form pre-filled

The board is **optional** — pay, claim, and audit all work standalone for off-board engagements.

## 7. End-to-End Verifiable Flow

Tirai provides a complete, cryptographically verifiable pipeline from bounty creation to private payout:

1. Bounty posting and application matching
2. Project deposit into the Cloak Shield Pool
3. Off-chain ticket handoff to the researcher
4. Researcher claim to existing or fresh wallet
5. Auditor scan via viewing key — destination wallet structurally hidden

Each step is **independently verifiable** and enforced cryptographically.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://moai-3.gitbook.io/tirai-frontier/introduction/key-features.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.