# Overview

Vishwa is a pre-execution verification control layer for agent finance. It sits between what an AI agent decides and what actually executes on-chain, so funds can move autonomously without handing the agent blind trust.

Every action an agent proposes is submitted as an unsigned request through the Vishwa gateway and checked against the owner's constraints inside a hardware-sealed control layer - a Trusted Execution Environment (TEE) - before anything signs or settles. The agent never holds keys. If a request falls outside the owner's policy, it is denied before execution, not flagged after.

To date, Vishwa's control layer has verified more than $170M in capital allocated and managed under its guardrails.

### The model in one line

The owner defines the rules. The agent operates within them. The control layer enforces them.

### Two products, one control layer

**Vishwa CLI** is an agent-native console for on-chain finance across Solana, Base, and Pharos. You describe intent in plain English - check a wallet, browse Polymarket prediction markets, place or close a trade - and every action clears your sealed constraint policy before it executes. See the Vishwa CLI quickstart.

**Naro BTCvp Vault** is a guardrailed BTC yield vault on Pharos. Depositors mint BTCvp, a non-rebasing token backed by native BTC, while an AI coordinator (Naro) manages allocation within a curated strategy framework (Ciara) and an independent verification layer (Veta) checks every capital movement before execution. See the Vault Overview page.

### Who it's for

* **Individuals running agents.** Let an agent trade or manage funds inside hard limits you set once - per-trade caps, venue allow-lists, slippage bounds.
* **BTC holders.** Earn yield on native BTC without wrapping or bridging it, with every capital movement verified against predefined constraints.
* **Agent and strategy builders.** Build on a gateway where your agent proposes and independent infrastructure decides, so a bug or a hallucination cannot move funds outside policy.
* **Institutions.** Deploy capital through AI-coordinated strategies with enforced risk limits, auditable execution, and no key handover.

### Why a control layer, not just a smarter agent

Wallet policy engines see the shape of a transaction but not the market. Vishwa's control layer verifies intent, solvency, and execution fidelity - it pulls oracle and venue prices itself, so it can catch a bad fill that a transaction-level check cannot see. The verification proof replaces the human approval loop: no after-the-fact alerts, no irreversible surprises.

Nothing in this documentation is financial advice. Prediction markets and yield strategies carry risk.


# Vision

The total market capitalization of cryptocurrencies is approximately $2.5 trillion, with Bitcoin consistently accounting for 40% to 50% or more of this value.

And as an asset, BTC’s liquidity is only marginally reflected in the market.

Most holders are reluctant to directly sell or transact with their BTC. In addition, the BTC network is isolated from the ETH (EVM) network, preventing BTC from participating in DeFi through smart contracts.

The dramatic market fluctuations of 2020 and the debacle of 2022 forced many companies providing financial custody services for BTC to go bankrupt, causing Bitcoin holders to incur unprecedented losses.

This led to an increased demand for decentralized solutions that can provide liquidity avenues for BTC assets without the associated risks of centralized services.

On the other hand, with the emergence of program languages like RUST and MOVE, some high-performance non-EVM blockchains are beginning to attract user attention.

Furthermore, with the development of zero-knowledge proof technologies, an increasing number of secure and high-performance Layer 2 networks have gained market recognition.

However, different blockchains and networks employ disparate technologies, making leveraging asset liquidity across them challenging and furthering the lack of chain interoperability.

Vishwa is building an infrastructure that allows the liquidity from Bitcoin/EVM/Non-EVM blockchains to flow freely in a decentralized, trustless, permissionless, and censorship-resistant environment. Vishwa’s state channel infrastructure solution leads directly to chain abstraction through capital optimization. 

<br>

<br>


# Development Goals

The Vishwa Network has prioritized the development of the following business and tech features and welcomes your participation if you have a knack for what we are building:

Stage 1. (July.2024)

1. Testnet launch in experimental environment.&#x20;
2. BTC transfers quickly & 0 gas fee with high concurrency；

Stage 2. (September.2024)

1. Deploy collateralized loans by staking BTC to borrow stablecoins (e.g. $USDC or $USDT)
2. Stake BTC to release vBTC on any other Blockchain or Layer 2
3. Open applications to become Vishwa witness nodes

Stage 3. (Oct.2024)

1. Enable universal trading in the Vishwa dApp through the Omni-account
2. Re-stake (x)BTC&#x20;
3. Operationalize APIs to call Vishwa’s functions
4. Establish fiat currency transaction channels for digital currencies and enable OTC operations


# Core Concepts

### The pipeline: intent to execution

Every action in the Vishwa system follows the same path:

```
You / Agent  --->  Gateway (Vishwa API)  --->  Control layer (TEE)  --->  Execution
plain-English      receives the               verifies the request       signs & settles
intent             unsigned request           against your constraints   only on a passing proof
```

1. **You or your agent states intent** in plain English ("buy France 10 yes contracts in this market").
2. **The gateway** (`api.vishwalab.com`) receives the action as an unsigned request - a proposal. The agent cannot sign or send a transaction on its own.
3. **The control layer** runs the request through verification inside a Trusted Execution Environment (TEE), against a constraint policy sealed by the owner.
4. **Execution** happens only on a passing proof. The control layer signs and submits; a failing request is denied before anything irreversible occurs.

### The three checks

Every request is verified on three axes before it signs:

* **Authorization.** Is this agent allowed to take this action, on this venue? Operations and venues are allow-listed per agent.
* **Solvency and limits.** Is the request within the owner's per-trade, daily, and monthly caps, and covered by actual balances?
* **Execution fidelity.** Is the fill price within the owner's slippage tolerance against the live market? The control layer pulls oracle and venue prices independently, so it can reject a bad fill that a transaction-shape check would miss.

### Constraint policies

A constraint policy is the owner's rulebook, sealed inside the TEE. It is invisible to both the agent and the wallet - the agent only ever learns "allowed" or "denied."

```json
{
  "authorized_agents": [{
    "id": "agent:vishwa-cli",
    "allowed_operations": ["buy_contracts", "sell_contracts"],
    "per_operation_limits": {
      "buy_contracts": {
        "per_tx_usd": 20,
        "daily_usd": 100,
        "monthly_usd": 1000,
        "approved_venues": ["polymarket"],
        "max_slippage": 0.02
      }
    }
  }],
  "global_constraints": {
    "daily_limit_usd": 100,
    "rate_limiting": { "max_operations_per_minute": 5 }
  }
}
```

| Field                                      | What it enforces                                                           |
| ------------------------------------------ | -------------------------------------------------------------------------- |
| `allowed_operations`                       | Which actions the agent may take (e.g. buy/sell only - never transfer out) |
| `approved_venues`                          | The allow-list of execution venues                                         |
| `per_tx_usd` / `daily_usd` / `monthly_usd` | Spend caps per trade, per day, per month                                   |
| `max_slippage`                             | How far a fill may drift from the live market price                        |
| `rate_limiting`                            | Maximum operations per minute - blocks runaway loops                       |

### The operating roles: Ciara, Naro, Veta

In vault deployments, the control-layer model is expressed as three named roles:

* **Ciara - the curator.** Defines approved strategies, allocation frameworks, and risk parameters: the rules the vault may operate under.
* **Naro - the AI coordinator.** Monitors positions, liquidity, market conditions, and opportunities; proposes or triggers allocation, rebalancing, and de-risking within Ciara's framework.
* **Veta - the verification layer.** Independently checks every capital movement against the predefined constraints before execution. Naro cannot move capital on its own.

In short: Ciara defines the rules, Naro operates within them, Veta enforces them. The same separation - proposer, policy, verifier - underlies the Vishwa CLI, where you are the curator of your own constraint policy.

### Key properties

* **The agent never holds keys.** It proposes; it cannot execute.
* **Constraints are sealed in hardware.** Neither the agent nor the wallet can read or alter the policy.
* **Verification is pre-execution.** A failing request is denied before signing - there is no approve-after-the-fact loop.
* **Market data is independent.** The control layer sources its own prices rather than trusting the agent's view of the market.
* **Every movement is auditable.** Executed actions return transaction signatures on-chain.


# Security

How verification-before-execution keeps funds within the limits you set.

Vishwa's security model rests on one architectural decision: verification happens before execution, inside hardware the agent cannot reach. Everything else follows from it.

### Non-custodial by design

In the CLI, the agent never holds keys - it submits unsigned requests through the gateway, and only the control layer can sign, only on a passing proof. In the vault, deposited BTC stays native (never wrapped or bridged) and remains subject to operational policies, risk limits, and verification rules throughout.

### Hardware-sealed policy

Constraint policies live inside a Trusted Execution Environment (TEE). Neither the agent proposing an action nor the wallet executing it can read or modify the policy; the agent only ever receives allowed or denied. This removes the two most common failure modes of agent finance: an agent talked (or hallucinated) into overstepping, and a policy quietly edited by the thing it constrains.

### Independent verification, three axes

Every request is checked for authorization (right agent, right action, right venue), solvency and limits (caps and balances), and execution fidelity (fill price against independently sourced market data). Because the control layer pulls oracle and venue prices itself, it can catch a bad fill that transaction-level policy engines cannot see.

### Fail-closed

A request that fails any check is denied before signing. There are no after-the-fact alerts, no approval queues racing against execution, and no irreversible action taken on an unverified request.

### Defense in depth

No single component is trusted alone: the proposer (agent or coordinator), the policy (owner- or curator-defined), and the verifier are separated by design. In vault deployments this appears as the Ciara / Naro / Veta split; in the CLI, as owner policy vs. agent vs. control layer. Rate limits bound the blast radius of any runaway loop, and every executed action leaves an auditable on-chain signature.

### Audits and disclosures

Five third-party audits cover the stack: FuzzLand's 2025 audits of the token contracts, BTC ZK-circuits, and light client; FuzzLand's June 2026 audit of the agent product (Vishwa CLI, Veta TEE Engine, Agent Service - 14 issues, none High or Critical); and ExVul's June 2026 audit of the Vishwa Proof Token (passed, 0 Critical/High). The Veta TEE Engine itself is covered by FuzzLand's audit. Summaries and reports are on Audits and Compliance. A public bug bounty program has not yet opened.

### Honest limits

The model reduces and bounds risk; it does not remove it. Strategy losses within policy limits, venue or counterparty failure, and custody risk remain possible. Constraints ensure capital cannot move outside the rules - they do not ensure the rules produce profits.


# Audits & Compliance

Security through transparency.

The Vishwa protocol undergoes rigorous third-party security audits to ensure the highest standards of safety. Our commitment to security goes beyond code review and includes formal verification, continuous monitoring, and comprehensive risk assessment.

## Completed Security Audits

<table><thead><tr><th>Auditor</th><th>Audit scope</th><th>Date</th><th>Status</th><th data-type="files">Report</th></tr></thead><tbody><tr><td>FuzzLand</td><td>Token contracts </td><td>08/20/2025</td><td>Completed ✅</td><td><a href="/files/nBZ1RsTSsBFHy6Y6npnh">/files/nBZ1RsTSsBFHy6Y6npnh</a></td></tr><tr><td>FuzzLand</td><td>BTC ZK-circuits</td><td>08/20/2025</td><td>Completed ✅</td><td><a href="/files/2dSkmZassApxIsm8N7BH">/files/2dSkmZassApxIsm8N7BH</a></td></tr><tr><td>FuzzLand</td><td>Light client</td><td>08/20/2025</td><td>Completed ✅</td><td><a href="/files/9yy50TUwhg6rla1xSqGS">/files/9yy50TUwhg6rla1xSqGS</a></td></tr></tbody></table>

## FuzzLand Security Audit

**Completion date:** August 2025

**Audit duration:** 4 weeks

**Techniques employed:** static analysis, fuzz testing, formal verification, and manual code review

**Summary:** 25 unit tests written, all code manually reviewed, 3 issues found (all resolved)

### FuzzLand Security Audit - Agent Product

**Delivered:** 10 June 2026

**Scope:** Veta TEE Engine (`vishwanetwork/veta-server`), Vishwa MCP Server (`vishwanetwork/vishwa-cli`), and Vishwa Agent Service (`vishwanetwork/agent-api`), each audited at a pinned commit

**Effort:** 12 person-days - 4 engineers over 3 days

**Techniques employed:** static analysis, fuzz testing, formal verification, and manual code review

**Findings:** 14 issues - 5 Medium, 9 Low, no High or Critical. Findings centered on pre-sign intent binding, x402 payment handling, and gateway authentication.

**Remediation:** fix commits for the Vishwa MCP Server and Agent Service are recorded in the report. The Veta TEE Engine is off-chain code, so no on-chain fix-commit hash applies.

### ExVul Security Audit - Vishwa Proof Token

**Completion date:** June 2026

**Scope:** Vishwa Proof Token contracts - BTCvp (`0x79D154287DDC77e5C10127E68c2df1a942a330BB`) and Cfvc (`0xa3b81AA35A2462c588639483EBe68a856Cb32b0d`), from `vishwanetwork/lightclient-verifier` at a pinned commit

**Techniques employed:** OWASP-based risk assessment - static analysis, manual review, and business-logic scrutiny

**Findings:** 5 issues - 0 Critical, 0 High, 3 Medium, 2 Low. Four are fixed; one Medium (arbitrary `srcRef` bytes not canonically constrained on-chain) is acknowledged.

**Result:** audit passed.

### Disclaimer

No audit guarantees the absence of vulnerabilities. Audits are point-in-time reviews of pinned commits; they complement, rather than replace, ongoing security practices. A public bug bounty program has not yet opened.

{% file src="/files/3oWvgD8SCUvPuh1EysLc" %}

{% file src="/files/BRkc2VidObjHsYkN1Ub3" %}


# Bug Bounty Program

Work in progress


# FAQ

### General

**What is Vishwa?** A pre-execution verification control layer for agent finance. AI agents propose actions in plain English; a hardware-sealed control layer verifies each one against the owner's constraints before anything signs or settles.

**Does the agent hold my keys?** No. The agent submits unsigned requests through the Vishwa gateway. Only the control layer signs, and only when a request passes verification.

**What stops an agent from overspending or going rogue?** The constraint policy: allowed operations, venue allow-lists, per-trade/daily/monthly caps, slippage bounds, and rate limits, sealed in a TEE the agent cannot read or modify. A request outside policy is denied before execution.

### Vishwa CLI

**What can I do with the CLI today?** Check your wallet, browse Polymarket prediction markets, and place or close trades - all in plain English. Supported chains are Solana, Base, and Pharos.

**Do I need to learn commands?** No. You describe intent ("buy France 10 yes contracts in this market"); the agent handles orderbooks, venue rules, and execution, and explains what it did.

**What happens if my order violates my limits?** The control layer denies it before signing. The agent reports that it cannot proceed.

### Naro BTCvp Vault

**What is BTCvp?** A BTC-backed proof-of-asset token on Pharos, minted against native BTC. It is non-rebasing and yield-accruing: your balance stays flat while the redemption value (NAV) reflects vault performance.

**What are Naro, Ciara, and Veta?** Ciara defines the rules (approved strategies, allocation frameworks, risk parameters). Naro, the AI coordinator, operates within those rules. Veta independently verifies every capital movement before execution.

**Where is my BTC held?** Native BTC remains in custody - never wrapped or bridged - and backs BTCvp throughout its lifecycle.

**How is yield generated?** Through institutional market-neutral and delta-neutral strategies - hedged arbitrage, funding-rate capture, liquidity deployment - coordinated by Naro within Ciara's framework and verified by Veta. Returns depend on realized performance and are not guaranteed.

**How do I deposit?** Through the vault interface, from a Bitcoin wallet you control, with a Pharos EVM wallet connected to receive BTCvp. Never deposit directly from an exchange - exchange withdrawals can't carry the routing information that directs minting to your address. See the Depositing BTC page.

**How do I redeem, and how long does it take?** Use the Redeem tab; BTCvp is burned and native BTC settles to your Bitcoin wallet. Deposits take \~6 Bitcoin confirmations (\~60 minutes); redemptions are subject to a T+7 notice period.

**Why might my redeemed BTC differ from my deposit?** Yield accrues to BTCvp's redemption value rather than your token balance, so each BTCvp may redeem for more (or, with negative performance, less) BTC than at mint.

***

Nothing here is financial advice. Prediction markets and yield strategies carry risk.


# Vishwa CLI

Vishwa CLI is an agent-native console for on-chain finance across Solana, Base, and Pharos. You describe intent in plain English; every action is submitted as an unsigned request through the Vishwa gateway and verified against your constraints inside a hardware-sealed control layer before anything executes.

Start with the Quickstart, then set your guardrails in Setting Your Constraints.


# Quickstart

Vishwa CLI is an agent-native console for on-chain finance on Solana. You never type flags or memorize commands - you describe what you want, and every action is verified against your constraints before it executes.

## Prerequisites

* **Node.js 18+** and **npm**
* A terminal
* A Vishwa account - created during sign-in

Check Node is installed:

```bash
node --version
npm --version
```

## Install and sign in

Vishwa ships as an agent skill. Point your agent at the install guide and it handles the rest:

```
Install Vishwa from https://api.vishwalab.com/skills/vishwa-cli/skill.md
```

The agent will:

1. **Check prerequisites** - confirms Node.js and npm are present.
2. **Install the CLI globally** via npm (`vishwa-cli`).
3. **Sign you in:**

   ```bash
   vishwa-cli login
   ```

   This opens your browser to `vishwalab.com/auth/login`. Approve the session and the CLI is connected to the Vishwa gateway. Your agent wallet is created or linked automatically.

When this finishes you have a working CLI bound to your Vishwa wallet, with every request routed through the gateway into the control layer.

## Before you trade: set your constraints

Do not skip this. Before the agent can move anything, define the guardrails the control layer will enforce - allowed operations, venues, and spend caps. See [Setting Your Constraints](broken://pages/bc3ffecb5021d68f2932ceaea8e3e094006d6963).

## Your first session

Once constraints are set:

```
get my wallet
show me the polymarket hot events
```

From there, open a market by name, place a trade, and review positions - all in plain English. See [Using the CLI](broken://pages/5c925d7a4f4e7a002b70a10feb9e64c7ed1a5050) for the full walkthrough.


# Setting Your Constraints

This is the foundation of the Vishwa model. Before the agent can move a cent, the fund owner seals a constraint policy into the control layer. The agent never sees the full policy - it only ever gets allowed or denied.

### Express limits in plain English

```
set my limits: only trade on Polymarket, max $20 per trade,
$100 per day, buy and sell contracts only - no transfers
```

Under the hood this becomes a signed constraint policy sealed inside the TEE:

```jsonc
{
  "authorized_agents": [{
    "id": "agent:vishwa-cli",
    "allowed_operations": ["buy_contracts", "sell_contracts"],
    "per_operation_limits": {
      "buy_contracts": {
        "per_tx_usd": 20,
        "daily_usd": 100,
        "monthly_usd": 1000,
        "approved_venues": ["polymarket"],
        "max_slippage": 0.02
      }
    }
  }],
  "global_constraints": {
    "daily_limit_usd": 100,
    "rate_limiting": { "max_operations_per_minute": 5 }
  }
}
```

### What each field controls

| Constraint                                 | What it enforces                                                           |
| ------------------------------------------ | -------------------------------------------------------------------------- |
| `allowed_operations`                       | Which actions the agent may take (e.g. buy/sell only - never transfer out) |
| `approved_venues`                          | The allow-list of execution venues (e.g. Polymarket)                       |
| `per_tx_usd` / `daily_usd` / `monthly_usd` | Spend caps per trade, per day, per month                                   |
| `max_slippage`                             | How far the fill price may drift from the live market                      |
| `rate_limiting`                            | Max operations per minute - blocks runaway loops                           |

### What happens after sealing

Every subsequent action is checked against this policy automatically. A buy that would exceed `per_tx_usd`, hit an un-approved venue, or fill outside `max_slippage` is denied before it ever signs. The agent simply reports that it cannot proceed.

Note: in the current release, these guardrails are configured as predefined examples rather than set through a user-facing command. The plain-English and JSON examples above illustrate the control-layer policy model.


# Using the CLI

Everything below happens in plain English. Each action is submitted as an unsigned request through the gateway and cleared by the control layer before it executes. Figures shown are example values from a recorded demo session and will differ from your live account.

## Check your wallet

```
get my wallet
```

You get a live on-chain snapshot - the same balance the control layer reads independently when it checks solvency:

| Field       | Example                    |
| ----------- | -------------------------- |
| Address     | your Solana address        |
| SOL balance | 0.0951 SOL                 |
| Tokens      | USDC: 10.38, JupUSD: 10.26 |

## Browse prediction markets

Vishwa connects to Polymarket:

```
show me the polymarket hot events
```

Then drill into a market by name:

```
2026 FIFA World Cup Winner
```

The agent returns a ranked table of outcomes with live prices and volume, and explains the mechanics: each outcome is a Yes/No market; buying "Yes" at $0.162 pays $1.00 per share if that outcome wins. Prices move as people trade, and eliminated outcomes settle to "No."

## Place a trade

```
buy France 10 yes contracts in this market
```

The agent:

1. **Looks up the live orderbook** for the best available ask.
2. **Handles venue rules.** Polymarket enforces a $5 minimum order; if your request is below it, the agent scales the order to the minimum and tells you why before committing.
3. **Submits the request through the gateway**, where the control layer verifies it against your policy: operation allowed, venue approved, cost within per-trade and daily caps, fill within slippage of the live book.
4. **Signs and submits** - only because the request passed. You get a confirmation with the transaction signature.

If the order had exceeded your per-trade cap or hit an un-approved venue, the control layer would deny it before signing.

## Check your positions

```
show me my positions
```

Per position you see contracts held, average purchase price, cost basis, current mark, open orders, and unrealized P\&L. You can claim the payout if the outcome wins, or sell any time before resolution.

## Close a position

```
sell all contracts in this position
```

The exit is verified the same way as the entry - request through the gateway, cleared by the control layer - then filled at the live bid and confirmed with a transaction signature and a round-trip summary.

## Session recap

```
get my wallet
```

Asking again at the end of a session shows a before/after view: balance changes per asset, fees, and a plain-English recap of the session's net result.


# Command Reference

You describe intent; the agent handles the rest. The phrases below are starting points, not fixed syntax.

| You want to...   | Just say...                                                                  |
| ---------------- | ---------------------------------------------------------------------------- |
| Set guardrails   | "set my limits: only Polymarket, max $20/trade, $100/day, buy & sell only"   |
| Install          | "Install Vishwa from <https://api.vishwalab.com/skills/vishwa-cli/skill.md>" |
| Sign in          | `vishwa-cli login` (the agent runs this for you)                             |
| See balances     | "get my wallet"                                                              |
| See markets      | "show me the polymarket hot events"                                          |
| Open a market    | "2026 FIFA World Cup Winner"                                                 |
| Buy              | "buy France 10 yes contracts in this market"                                 |
| View holdings    | "show me my positions"                                                       |
| Close            | "sell all contracts in this position"                                        |
| Review a session | "get my wallet"                                                              |

Currently supported: Solana wallets (SOL, USDC, JupUSD), Polymarket prediction markets, Jupiter (Solana swaps), and Ondo (tokenized assets).


# Naro BTCvp Vault

Naro BTCvp Vault is a guardrailed BTC yield vault on Pharos. Native BTC is held in custody and BTCvp - a non-rebasing, NAV-accruing token - is minted against it, while Naro (AI coordinator), Ciara (curator), and Veta (verification layer) operate the vault inside enforced constraints.

Start with the Vault Overview, then see Depositing BTC and Redeeming BTC.


# Vault Overview

Naro BTCvp Vault gives BTC holders yield exposure without wrapping, bridging, or giving up BTC backing. Deposited BTC is held in custody; BTCvp - a proof-of-asset token on Pharos - is minted against it 1:1 and recorded on-chain.

BTCvp is non-rebasing: yield accrues to the token's redemption value (NAV) rather than to your balance. Your token count stays flat while each BTCvp may become redeemable for more BTC over time, if the vault generates positive returns. Yield is indicative and depends on realized vault performance - it is not guaranteed.

### Vault facts

|                        |                                                                                  |
| ---------------------- | -------------------------------------------------------------------------------- |
| Token                  | BTCvp (non-rebasing, NAV-accruing)                                               |
| Network                | Pharos (Pacific)                                                                 |
| Backing                | Native BTC held in custody, 1 BTCvp = 1 BTC at mint                              |
| Deposit confirmation   | 6 Bitcoin confirmations (\~60 minutes)                                           |
| Deployment date        | 10 June 2026                                                                     |
| Indicative average APY | 6.55% (as displayed on vault.vishwalab.com, July 2026 - varies with performance) |
| Performance fee        | Not displayed on the vault interface (shown as "-")                              |
| Custodian              | Ceffu                                                                            |

### How yield is generated

Yield comes from institutional market-neutral and delta-neutral strategies coordinated by Naro and settlement partners - hedged arbitrage, funding-rate capture, liquidity deployment, and other risk-managed opportunities. The vault is designed to avoid leveraged directional exposure.

All capital movements remain subject to two controls:

* **Ciara's strategy framework** - the approved strategies, allocation limits, and risk parameters the vault may operate under.
* **Veta's execution verification** - an independent check of every capital movement against allocation, leverage, venue, counterparty, liquidity, redemption, and risk constraints, before execution.

### What the AI coordinator can and cannot do

Naro continuously monitors positions, exposure, market conditions, liquidity, margin, and redemption needs, and proposes or triggers allocation, rebalancing, strategy routing, and de-risking actions.

It cannot move capital on its own. Every action is independently verified and enforced by Veta; capital moves only if the constraints are satisfied, and every movement remains auditable.

### Where your BTC is held

Your BTC is never wrapped or bridged. Native BTC remains in custody with Ceffu and backs BTCvp throughout its lifecycle. Custodied BTC is subject to approved operational policies, risk limits, and verification rules at all times.


# Depositing BTC

## What you need

Two wallets:

* **A Bitcoin wallet you control** - to send BTC. Not an exchange account.
* **A Pharos EVM wallet** - to receive and hold BTCvp. The connected Pharos address becomes the mint recipient.

Minimum deposit: 0.0001 BTC.

## How it works

1. Connect both wallets on [vault.vishwalab.com](https://vault.vishwalab.com/).
2. Use the **Mint** tab. The interface associates your deposit with your connected Pharos address.
3. Send BTC from your connected Bitcoin wallet to the displayed custody address.
4. After 6 Bitcoin confirmations (about 60 minutes), the deposit is detected and BTCvp is minted to your Pharos wallet at approximately 1:1 (8 decimal places).

## Do not deposit from an exchange

Always deposit through the interface from a Bitcoin wallet you control. Exchange withdrawals cannot carry the routing information that directs minting to your Pharos address, and may require manual recovery.


# Redeeming BTC

### How it works

1. Use the **Redeem** tab on [vault.vishwalab.com](https://vault.vishwalab.com).
2. Your BTCvp is returned and burned.
3. Native BTC is settled from custody to your designated Bitcoin wallet.

### Timing

Redemptions are subject to a T+7 notice period. Once the notice period has passed, native BTC is settled from custody to your designated Bitcoin wallet; larger requests may take longer to allow orderly settlement and liquidity management.

### Why your redeemed BTC may differ from your deposit

BTCvp accumulates BTC-denominated yield through the vault's strategies. Yield is reflected in the redemption value (NAV), not in your token balance - so each BTCvp may redeem for more BTC than at mint if the vault has generated positive returns. Redemption value can also reflect negative performance; returns are not guaranteed.


# Risk and Governance

### The layered operating model

BTCvp is governed through separation of duties:

* **Ciara (curator)** defines the approved strategy and risk framework - which strategies are allowed, how capital may be allocated, what limits apply.
* **Naro (AI coordinator)** operates the vault within that framework - monitoring, allocating, rebalancing, de-risking.
* **Veta (verification layer)** independently verifies every capital movement against the predefined constraints before execution.

No single component can move capital unilaterally. Custodied BTC remains subject to approved operational policies, risk limits, and verification rules at all times, and administrative controls remain subject to approved governance and operational procedures.

### Liquidation risk

The vault is built around market-neutral and delta-neutral strategies intended to reduce directional liquidation risk rather than take leveraged directional exposure. Leverage, venue, counterparty, liquidity, and risk limits are enforced by Veta on every action; Naro monitors positions continuously and can de-risk when predefined thresholds are reached.

### What can still go wrong

Risk-managed is not risk-free. Depositors should understand that:

* **Strategy risk.** Market-neutral strategies can underperform or lose money; APY figures are indicative, not promised.
* **Counterparty and venue risk.** Strategies execute on external venues within Veta's limits, but venue failure remains a possibility.
* **Custody risk.** Native BTC is held with Ceffu under operational policies. See Audits and Compliance for third-party audit reports.
* **Redemption timing risk.** The T+7 redemption notice period means BTC is not instantly withdrawable.

See Audits and Compliance for third-party audit reports covering the token contracts, circuits, and control layer.