> ## Documentation Index
> Fetch the complete documentation index at: https://docs.inkwell.finance/llms.txt
> Use this file to discover all available pages before exploring further.

# Inkwell P2P Lending Protocol RFP Proposal

> Non-custodial zero-trust cross-chain P2P lending via Ika 2PC-MPC on Sui

> **CONFIDENTIAL & PROPRIETARY - SOLICITED PROPOSAL © 2026 Inkwell Finance, Inc. All Rights Reserved. Commercial use, reproduction, or distribution prohibited without written agreement with Inkwell Finance, Inc.**

## Executive Summary

<Columns cols={2}>
  <Card title="Problem" icon="triangle-exclamation">
    Liquidity is fragmented across chains; BTC and other assets can’t be used as collateral cross‑chain without trust trade‑offs.
  </Card>

  <Card title="Solution" icon="wand-magic-sparkles">
    Non‑custodial, cross‑chain lending via Ika’s 2PC‑MPC and Sui’s parallel execution using least‑privilege, time‑bound capabilities.<br />
    No pools; bilateral P2P.
  </Card>

  <Card title="Differentiation" icon="shield-halved">
    No standing keys; pre‑signed, verifiable flows; security‑first SDLC; compliance‑first design.<br />
    No pools; bilateral P2P.
  </Card>

  <Card title="Why now" icon="clock">
    MPC infra maturity, robust oracles, and demand for BTC collateral utility unlock better UX and security.
  </Card>

  <Card title="RFP ask" icon="hand-holding-dollar">
    Seed grant of \$100k to deliver the RFP deliverables (8–12 weeks).
  </Card>

  <Card title="Roadmap (high level)" icon="road">
    M1: BTC→USDC on Sui testnet<br />M2: extend to Ethereum/Solana<br />M3: advanced risk + audits<br />M4: mainnet + liquidity
  </Card>
</Columns>

<Note>
  Inkwell enables native, non‑custodial cross‑chain collateralization by combining a user‑owned key share with a decentralized MPC cluster and a protocol‑held DWalletCap-avoiding both custodial and pooled‑trust assumptions.
</Note>

## Project Overview

<Note>
  No shared liquidity pools. All loans are bilateral P2P contracts. The protocol coordinates checks and uses a protocol‑held DWalletCap to sign within scope; it never shares that capability with users, relayers, or keepers.
</Note>

The core value of Inkwell Finance lies in solving a \$10 trillion inefficiency through true cross-chain lending without trust assumptions.

Inkwell Finance addresses the fundamental problem of liquidity fragmentation across blockchain networks. Currently, Bitcoin holders can't use their \$1.3T in assets for DeFi lending, and users with cross-chain portfolios can't efficiently leverage their entire holdings. Existing solutions force impossible trade-offs between security, decentralization, and user experience.

Our approach leverages Ika's revolutionary 2PC-MPC technology and Sui's parallel execution to enable users to deposit Bitcoin as collateral for Ethereum loans, or use any supported asset across any supported chain - all while maintaining true ownership through non-custodial MPC wallets. We're not building another bridge; we're creating the infrastructure for a unified, multi-chain financial system where liquidity flows as seamlessly as ink across paper.

<Tip>
  <strong>References</strong>

  * BTC market capitalization and liquidity figures: [https://coinmarketcap.com/](https://coinmarketcap.com/)
  * Cross-chain liquidity fragmentation estimates: industry reports and public crypto market data aggregations
  * Ika 2PC‑MPC technical docs: [https://ika.org/](https://ika.org/)
  * Pyth price feeds and coverage: [https://pyth.network/](https://pyth.network/)
</Tip>

## Competitive Positioning (trust model archetypes)

* Wrapped assets (wBTC): centralized/federated custody → single point of failure.
* Bridge w/ DVNs (LayerZero): verification outsourced to third‑party networks.
* Decentralized liquidity (THORChain): pooled, economic trust in validator set.
* Inkwell: user key share + decentralized MPC + protocol‑held DWalletCap → non‑custodial, no pools, least‑privilege signing.

## Alternatives & Differentiation

* Bridges and wrapped assets: introduce custodial or economic trust, standing signing authority, and bridge-specific risk; UX friction and fragmentation remain.
* Threshold custody and restaked bridges: reduce but do not eliminate trust; complex economic security that can degrade under stress.
* Cross-chain liquidity networks (e.g., swaps/routers): enable movement, not position‑level collateralization across chains.
* Inkwell difference: no standing keys, least‑privilege/time‑bound DWalletCap, pre‑signed envelope execution with on‑chain invariants; unified position across chains without bridges.

## Team Pitch

<Columns cols={1}>
  <Card title="Lars van der Zande" icon="user-astronaut" href="https://x.com/Lmvdzande">
    Lead Architect - 5+ years blockchain (Solana); 10+ years full‑stack + DevOps.

    Lars brings 5+ years of blockchain development experience on Solana and 10+ years of web2 full-stack and DevOps expertise. As the Lead Architect, he's responsible for the technical vision and implementation of Inkwell's cross-chain lending protocol. He's currently serving as interim CEO and CFO until the team completes hiring for these roles.
  </Card>

  <Card title="Guru" icon="paintbrush" href="https://x.com/gurusaidwhat">
    Graphics & UI/UX - 5+ years designing intuitive interfaces for web2 & web3.

    Guru has 5+ years of experience designing intuitive interfaces for both web2 and web3 applications. He focuses on creating user-friendly experiences that abstract the complexity of cross-chain operations, making DeFi lending accessible to a broader audience.
  </Card>

  <Card title="Gregory Nicholas" icon="handshake" href="https://x.com/gregorynich">
    Business Development - Strategic partnerships and ecosystem growth.

    Gregory brings extensive experience in business development and strategic partnerships. He's responsible for building relationships with RWA issuers, institutional partners, and ecosystem stakeholders to drive adoption of Inkwell's cross-chain infrastructure.
  </Card>
</Columns>

<Note>
  Open roles (post‑grant / investor‑funded):

  * DeFi Protocol Engineer - lending protocol, risk, liquidation engine
  * Security Engineer - auditor background, cross‑chain vectors
  * DevOps / Infra Engineer - large‑scale blockchain infra
  * Community / Marketing & Growth
</Note>

### Team Hiring Timeline

* Seed grant phase: executed by current core contributors; additional hires deferred to investor-funded stage.
* Post-grant: begin full hiring once PoC validated; target 1 month from investor close for all roles.

## Month-1 Barebones Demo

### Objective

Deliver a minimal but real end-to-end demo that exercises Ika 2PC-MPC with Sui orchestration to prove feasibility and momentum within \~4 weeks.

### Non-goals

* Production-grade risk engine or liquidations automation
* Multi-chain integrations beyond BTC testnet and Sui testnet
* Full UI polish (CLI + minimal web page is sufficient)

### Scope & Demo Deliverables

* Ika integration
  * Start localnet Ika stack
  * Create borrower and lender dWallets via TypeScript scripts
  * Obtain limited, time-bound DWalletCaps for: deposit BTC collateral; disburse USDC loan;
* Sui Move minimal protocol (MVP)
  * Events for audit trail: DepositRequested, DepositConfirmed, LoanDisbursed, RepayConfirmed
* Presign + Verify flows
  * Pre-sign BTC deposit and USDC disbursement envelopes with on-chain guardrails (scope + expiry + price check)
  * Verify envelopes in Sui before emitting requests to relayer

<Tip>
  <strong>Per-chain TTLs</strong>

  * <strong>Sui:</strong> Envelopes include <code>validUntil</code> (time/epoch) and a nonce; Move verifies these before the protocol uses its DWalletCap.
  * <strong>Solana:</strong> Transactions must reference a recent blockhash and lastValidBlockHeight (\~2 min TTL). Presigned Solana paths must broadcast within this window (or use nonce accounts if needed).
  * <strong>EVM:</strong> No native expiry; include a <code>deadline</code> in calldata/EIP‑712 and check it in-contract. We still gate signing on Sui by <code>validUntil</code>.
  * <strong>Bitcoin:</strong> No native expiry; we rely on Sui <code>validUntil</code> and immediate broadcast. Optional script-level constraints (CSV/CLTV) are possible but add complexity.

  Note: The protocol holds the DWalletCap and never shares it with users, relayers, or keepers; per‑chain TTLs just add defense‑in‑depth.
</Tip>

* Relayer (barebones)
  * Accepts signed envelopes for BTC deposit and broadcasts to Bitcoin testnet
  * Polls Bitcoin testnet and submits confirmation back to Sui via oracle runner
* Oracle runner (minimal)
  * TX-confirmation feed for BTC deposit into Sui (block hash/txid inclusion)
* CLI + thin demo web page
  * One-click (scripted) happy-path: create wallets → request deposit → confirm → disburse → repay
  * Record a 2–3 minute video demonstrating the sequence and invariants

### Success Criteria (Month-1)

* Happy-path run completes on camera and in logs with on-chain Sui events and BTC testnet txid
* All Ika calls use zero-trust, pre-signed flows; no standing signing authority
* Written demo guide + setup instructions committed to repo

### Evidence to Share with Ika

* Demo video + txids/objects links
* Repo pointers: Move contracts, runners, CLI scripts

<Info>
  <strong>Grant award condition</strong><br />
  Acceptance of the Proposal triggers the \$100k award split into milestone deliverables; funds are dedicated to the barebones RFP deliverables. Desirable features beyond this scope proceed with investor funding.<br /><br />
  Short technical note: capability scopes, expiry logic, and guardrails used.
</Info>

### Timeline (4 weeks)

* Week 1: Ika + Environment
  * ika start local stack wired into repo; TS scripts to create borrower/lender dWallets
  * Define DWalletCap scopes and expiries for deposit/loan
* Week 2: Sui MVP + Presign/Verify
  * Pre-sign deposit and disbursement envelopes; Sui-side verification logic
* Week 3: Relayer + Oracle
  * Barebones relayer broadcasts BTC testnet deposit; oracle runner confirms inclusion to Sui
* Week 4: End-to-End + Packaging
  * Wire repay path; run full demo; harden logs and error handling
  * Record video; prepare concise README for Ika review

### Dependencies & Coordination

* Ika: localnet 2PC-MPC presign/sign endpoints; assistance on capability scoping best practices
* Sui: localnet accounts, faucet; minimal USDC test token (faucet or dev-mint for demo)

### Risks & Mitigations

* Ika API changes → Keep integration thin; schedule weekly sync; feature-flag endpoints
* BTC testnet instability → Multi-node providers; retry/backoff; allow manual confirmation fallback for demo
* Sui localnet USDC deployment → availability; dev-mint if needed
* Cross-component timing/race issues → Use explicit state machine in Move; idempotent relayer submits; TTLs

### Stretch (time-permitting)

* Minimal Keeper to alert on health factor breaches (no auto-liquidation)

## RFP Funding Request

\$100,000 (flexible: \$50k–\$100k)

Purpose: Seed grant to deliver a PoC/testnet MVP that validates Ika 2PC‑MPC integration and Sui orchestration. Larger audit, mainnet, and GTM costs are intended to be investor‑funded.

Award trigger and use of proceeds: the \$100k is payable upon acceptance of the Month-1 Barebones Demo and is earmarked to fund the barebones deliverables listed in documentation/RFP.md#deliverables. Desirable features beyond this barebones scope will be investor-funded thereafter.

### RFP Scope and Deliverables (8-12 weeks)

* End-to-end BTC→USDC borrowing and repay on Sui testnet v Ika 2PC‑MPC
* Minimal Relayer, Keeper, and Oracle (Pyth) integration
* Least‑privilege, time‑bound DWalletCaps; pre‑signed envelopes with on‑chain checks
* Internal security review + threat model; incident runbook v0
* Simple web UI + CLI runner; demo video and technical docs
* Timeline: raw demo within 1 month (show initiative); polished deliverables 8–12 weeks
* Outputs: testnet demo, docs, and investor materials for next funding stage

## RFP Milestones, Roadmap & Budget

This section defines the short, grant-scoped execution plan tied to the \$100k award and the Month-1 Barebones Demo.

### Barebones Demo (Weeks 1–4)

* Scope (barebones subset of Deliverables):
  * Minimal Sui MVP contracts enforcing zero-trust lending logic with events
  * dWallet integration via Ika 2PC-MPC: presign/sign for deposit, disburse, repay
  * Minimal Oracle + Relayer runners (BTC testnet tx confirmation; price guardrail via Pyth or static fallback)
  * CLI + minimal UI for happy-path demo; demo video + repo pointers
* Budget \$40,000
  * Development \$24k - Sui MVP contracts; presign/verify flows; CLI + minimal UI; Ika wiring
  * DevOps \$6k - localnet stacks; CI; logging/metrics for demo
  * Design \$2k - minimal UI scaffolding for demo clarity
  * Security \$3k - internal review of capability scope/expiry, invariant checks
  * Contingency \$5k - BTC testnet instability, Ika API changes, retries/backoff

<Expandable title="Acceptance criteria">
  - On-chain Sui events + BTC testnet txid recorded
  - No standing signing authority; least-privilege, time-bound capabilities
  - Envelope scope/expiry checks enforced on-chain
</Expandable>

### Testnet MVP (Weeks 5–8)

* Harden presign/verify logic, error handling, and observability
* Internal security review + initial threat model; incident runbook v0
* Testnet deployment using BTC testnet collateral and Sui testnet USDC
* Documentation: setup + demo guide
* Budget \$45,000
  * Development \$22k - harden flows; error handling; observability; testnet deployment
  * DevOps \$6k - environments, monitors/alerts, testnet infra costs
  * Design \$5k - testnet UX clarity and demo polish
  * Security \$5k - initial threat model, incident runbook v0
  * Contingency \$7k - coordination with oracles/relayer; network variance

### Optional (Weeks 9–12)

* Replace static price guardrails with live Pyth in all checks
* Minimal Keeper alerting (no auto-liquidation) time-permitting
* Light UI polish for demo clarity
* Budget \$15,000
  * Development \$4k - Pyth integration in all checks; small keeper alerting; minor UI polish
  * DevOps \$3k - monitoring/metrics expansion; load tuning
  * Design \$3k - final pass on demo clarity
  * Security \$2k - additional hardening/tasks from threat model
  * Contingency \$3k - buffer or revert to prior phases if unused

## Budget Roll-up

* Development: 24 + 22 + 4 = \$50k
* DevOps: 6 + 6 + 3 = \$15k
* Design: 2 + 5 + 3 = \$10k
* Security: 3 + 5 + 2 = \$10k
* Contingency: 5 + 7 + 3 = \$15k
* Total: \$100k

### GTM (first 8 weeks)

* Weeks 1–4: Stand up channels (X, Discord, Telegram); publish technical explainers and demo threads; engage dev relations.
* Weeks 5–8: Targeted outreach to whales/MMs; LBP/presale mechanics; fee rebates; contribution‑based airdrops for high‑signal participation.

### RFP Budget

* Total: \$100,000

<Columns cols={2}>
  <Card title="Development" icon="code">\$50,000</Card>
  <Card title="DevOps & Infrastructure" icon="server">\$15,000</Card>
  <Card title="Design & UX" icon="palette">\$10,000</Card>
  <Card title="Security (internal)" icon="shield">\$10,000</Card>
  <Card title="Contingency / Ika support / misc" icon="circle-question">\$15,000</Card>
</Columns>

Notes

* The \$100k funds the barebones RFP deliverables above; desirable features proceed with investor funding thereafter.

## Post-RFP Roadmap and Projected Budget

<Note>
  Post‑RFP planning disclaimer: The roadmap, GTM, and budgets below are directional and subject to change as we complete research, hiring, audits, and partner diligence. Treat this as a starting point for future planning, not a commitment.
</Note>

<Expandable title="View Post‑RFP Roadmap">
  Note: The following Expenses and Milestones are forward-looking projections to be covered by investor capital and are not part of this RFP request.

  Investing Target: \$2.5M

  ### Expenses

  * Development: \$600,000
  * Design & UX: \$250,000
  * Security Audits: \$500,000
  * DevOps & Infrastructure: \$250,000
  * Community & Marketing: \$300,000
  * Talent Acquisition: \$100,000
  * Legal & IP: \$200,000
  * Compliance & Regulatory: \$200,000
  * Contingency: \$100,000
  * Total: \$2,500,000

  ### Milestone and Budget Proposal

  * Milestone 1: Core Protocol Foundation (\$1,100,000 - 6 months - 44%)

      <Expandable title="Budget">
        * Development (\$270,000)
        * Design & UX (\$150,000) (60% - core UI/UX design)
        * Security Audits (\$50,000) (initial review)
        * DevOps & Infrastructure (\$150,000) (60% - core infrastructure)
        * Legal & IP (\$200,000) (100% - IP and legal setup)
        * Compliance & Regulatory (\$200,000) (100% - regulatory framework)
        * Talent Acquisition (\$50,000) (100% - hiring costs)
        * Contingency (\$30,000)
      </Expandable>

    * Complete zero-trust p2p lending smart contracts
      * Borrower Create Loan
      * Borrower Cancel Loan
      * Lender Accept Loan
      * Withdraw Collateral (without forcing unhealthy LTV - liquidation)
      * Deposit Collateral (i.e. prevent liquidation)
      * Liquidate position
      * Repay position

    * Implement health factor calculations
      * LTV
      * Liquidation Threshold
      * Interest Rate Model

    * Oracle Network Infrastructure
      * access account data from external chains (RPC)
        * confirm proof of assets (requires DWalletCap to be under control of protocol)

    * Keeper Network Infrastructure
      * access price feed data from external chains (Pyth)
        * required to check for liquidatable positions

    * Relayer Network Infrastructure
      * relayer runner
        * request for position DWalletCap when needed
        * approve presigned liquidation and repay transactions
        * relay transactions to external chains
        * always return DWalletCap to protocol

    * Liquidation Infrastructure
      * liquidate positions when health factors are breached

    * Success: Functional cross-chain lending on Sui testnet with BTC-USDC lending pairs

    * Component Responsibilities (Milestone 1)
      * Relayer: request limited, time-bound capability; submit pre-signed repay/liquidation txs; always return capability to protocol
      * Liquidation: execute only when health factor breached; verify oracle and position state; no custody beyond scoped action

      <Expandable title="Acceptance Tests (excerpt)">
        - Borrow/repay lifecycle with BTC collateral and USDC debt on Sui testnet
        - Liquidation triggers at threshold; capability returned to protocol post-execution
        - Oracle outage: protocol pauses liquidation; resumes safely on recovery
        - Relayer delay: bounded retries with backoff; no erroneous liquidations
      </Expandable>

  * Milestone 2: Cross-Chain Integration (\$700,000 - 4 months - 28%)

      <Expandable title="Budget">
        * Development (\$180,000)
        * Design & UX (\$75,000) (30% - multi-chain UI)
        * Security Audits (\$100,000) (integration testing)
        * DevOps & Infrastructure (\$75,000) (30% - multi-chain infrastructure)
        * Community & Marketing (\$180,000) (early community building)
        * Talent Acquisition (\$50,000)
        * Contingency (\$40,000)
      </Expandable>

    * Extend cross-chain integration to Ethereum & Solana

    * Keeper Network Infrastructure
      * check for liquidatable positions
      * check for repayable positions

    * Success: Multi-chain testnet with BTC-USDC, ETH-USDC, and SOL-USDC lending pairs

    * Component Responsibilities (Milestone 2)
      * Keeper: continuously detect liquidatable/repayable positions; enqueue actions; no signing authority

      <Expandable title="Acceptance Tests (excerpt)">
        - ETH and SOL collateral/loan flows verified end-to-end
        - Keeper detects and schedules liquidations correctly; no action for healthy positions
        - Degraded network on one chain does not block others; alerts raised
      </Expandable>

  * Milestone 3: Advanced Features & Security (\$550,000 - 4 months - 22%)

      <Expandable title="Budget">
        * Development (\$100,000)
        * Design & UX (\$25,000) (10% - advanced features UI)
        * Security Audits (\$325,000) (major audit costs)
        * DevOps & Infrastructure (\$25,000) (10% - monitoring systems)
        * Community & Marketing (\$55,000) (pre-launch preparation)
        * Contingency (\$20,000)
      </Expandable>

    * Advanced risk analytics and multi-dimensional monitoring
      * Oracle Deviation Analysis
      * Market Condition Monitoring
      * Systemic Risk Monitoring
      * Dynamic Risk Scoring
        * Volatility Adjusted LTV
        * Correlation Adjusted LTV
        * Cascade Risk Modeling
        * Market Stress Testing
        * Real-Time Health Factor Evolution
    * Comprehensive security audits and formal verification
      * Security Audit from SlowMist/OtterSec

      <Expandable title="Acceptance Tests (additional)">
        - Keeper resilience: detects liquidations without false positives during price spikes; no action when HF >= threshold
        - Relayer safety: expired capabilities rejected; attempts outside scope rejected; all actions logged and auditable
        - Replay protection: identical pre‑signed envelopes are idempotent or rejected as per design
        - Deployment runbook completeness; incident response tabletop exercises performed
        - Audit gating: external reports show 0 critical, \<5 high; all remediations applied
        - Mainnet dry‑run (shadow mode) on testnets demonstrates monitoring/alerts within SLOs
      </Expandable>

    * Success: Audit-ready protocol with institutional-grade security & advanced risk management

  * Milestone 4: Production Deployment (\$150,000 - 2 months - 6%)

    * Budget:
      * Development (\$50,000)
      * Security Audit (\$25,000)
      * Community & Marketing (\$65,000) (launch marketing)

      <Expandable title="Acceptance Tests (expanded)">
        - Full mainnet deployment with canary rollout, observability checks, and rollback tested
        - Liquidity bootstrapping achieves >\$5M TVL within 30 days (acceptable threshold)
        - Post‑launch monitoring: 0 critical incidents in first 30 days; MTTR \< 4 hours for sev‑2 issues
      </Expandable>

    * Contingency (\$10,000)
    * Mainnet deployment on Sui, with support for BTC, ETH, SOL transactions
    * User interface and developer documentation
    * Community launch and liquidity bootstrapping
    * Success: Live protocol with \$10M+ initial TVL

  ### Projected Budget Notes

  * Category totals reconcile exactly with the Expenses overview; milestone totals remain unchanged.
  * Talent Acquisition: front‑loaded in M1 for initial hiring and in M2 to complete team formation for cross‑chain integrations.
  * Community & Marketing: weighted to M2–M4 to support multi‑chain testnet traction, pre‑launch preparation, and mainnet launch.
</Expandable>

## Security Posture

### Trust Model & Capability Flow

* No standing signing authority is ever granted. The protocol holds the least‑privilege, time‑bound DWalletCap for each position; it is never shared with users, relayers, or keepers.
* All sensitive actions are executed only by the protocol using its capability, after on‑chain checks: position state, price guardrails, and capability constraints (scope + TTL + nonce).
* Failure modes are bounded: delays only degrade liveness; safety is preserved by expiries/rotation and invariant checks before any signing.
* No external party ever receives a capability; actions are constrained by on‑chain checks and protocol‑held, non‑transferable capabilities.

### Borrow & Lend sequence

```mermaid theme={null}
sequenceDiagram
  participant I as Protocol (Ika)
  participant B as Borrower
  participant L as Lender
  participant W as Protocol (Inkwell)
  participant K as Keeper
  participant C as BTC Chain
  participant E as ETH Chain

  I->>B: Create dWallet
  B->>W: Open loan request & transfer DWalletCap
  I->>L: Create dWallet
  L->>W: Open loan proposal & transfer DWalletCap
  L<<-->>B: Agree on loan terms
  B->>C: Deposit Collateral into DWallet
  L->>E: Deposit Lending funds into DWallet
  B->>W: Confirm loan funds exists in lender_DWallet
  L->>W: Confirm collateral exists in borrower_DWallet
  B->>W: Create & Store Liquidation Presign Cap
  B->>W: Confirm Loan Acceptance
  L->>W: Confirm Loan Acceptance
  K->>W: Create and Attest Loan Contract
  W->>B: Receives Loan funds into borrower_DWallet
  B->>W: Request extraction of loan funds
  K->>W: Check for liquidation
  B->>W: Repay loan
```

### Liquidation sequence (simplified)

```mermaid theme={null}
sequenceDiagram
  participant B as Borrower
  participant L as Lender
  participant W as Protocol (Inkwell)
  participant K as Keeper
  participant R as Relayer
  participant C as BTC Chain
  participant O as Oracle

  K->>W: Detect Health Factor < Liq threshold
  W->>W: complete signing of liquidation tx cap
  W->>R: Liquidation Tx Signature
  R->>C: Submit fully signed liquidation tx
  C-->>O: Confirm liquidation tx
  O-->>W: Confirm tx
  W->>W: Settle loan & emit audit logs
  W->>L: Transfer Liquidation funds to lending dWallet or specific address based on loan contract
  W->>L: Transfer Lending DWalletCap
  W->>B: Transfer Borrowing DWalletCap
```

### Architecture Snapshot

```mermaid theme={null}
flowchart TD
  U[User]
  P[Inkwell]
  K[Keeper]
  O[Oracle]
  R[Relayer]
  BTC[Bitcoin]
  EVM[Ethereum]
  SOL[Solana]
  PY[Price Feeds Pyth]

  U -->|Open loan| P
  P -->|Signed TX| R
  R -->|Submit signed TX| BTC
  R -->|Submit signed TX| EVM
  R -->|Submit signed TX| SOL
  BTC -->|Await Confirm| O
  EVM -->|Await Confirm| O
  SOL -->|Await Confirm| O
  O -->|Confirm Tx| P
  PY -->|Prices| P
  K -->|Liquidation Health Check| P
```

<Note>
  <strong>Invariants</strong>

  * No standing signing authority; all capabilities are least‑privilege, time‑bound, and validated on use.
  * Critical actions gated by oracles, position state, and cap TTL/scope; replay attempts are rejected or idempotent.
  * Safety over liveness: on failures or delays, positions do not execute unsafe actions; capabilities expire and are recalled.
</Note>

<Note>
  There are no shared liquidity pools; each loan is a bilateral P2P contract. The protocol coordinates checks and signs using a protocol‑held DWalletCap; it never shares that capability with users, relayers, or keepers.
</Note>

### Parallel Liquidation Simulation (testnet)

* Goal: Demonstrate concurrent processing of N liquidation checks without race conditions.
* Setup: Testnet positions with varying health factors; controlled oracle deviation; relayer and keeper runners.
* Success:

  * ≥95% of eligible liquidations finalized within target window; 0 safety violations; all on‑chain invariants (scope, TTL, nonce, price bounds) hold.
  * Deterministic idempotency for duplicate envelopes; no double‑liquidations.
* Metrics: per‑chain inclusion latency; Sui verification guard time; relayer broadcast success; retries/error distribution.
* Artifacts: replayable dataset, on‑chain events/logs, public dashboard snapshot, written report.

### Threat Model (excerpt)

* Malicious relayer/front‑running: Neutralized by pre‑signed envelopes plus on‑chain DWalletCap checks (scope, TTL, nonce). Any deviation invalidates execution. Relaying is permissionless; censorship is mitigated by anyone‑can‑relay design.

## Assumptions & Dependencies

* Ika 2PC‑MPC: availability of presign/sign APIs and support during M1–M2.

* Oracles: Pyth coverage for BTC/ETH/SOL and stablecoins on target networks;

* Testnet/mainnet stability: Sui testnet reliability for M1; Ethereum/Solana testnets for M2.

* Audit scheduling: internal review by end of M1; external vendors reserved for M3; formal verification scope agreed.

* Compliance counsel available during M1 for architecture reviews and during M3 for launch readiness.

* Threat modeling: cross-chain attack surface, oracle dependencies, 2PC-MPC trust assumptions documented

* Secure SDLC: code reviews, property tests, fuzzing, invariants and simulation of failure modes

* Audits: internal review (M1); external audits (SlowMist/OtterSec) and formal verification of core safety-critical contracts (M3)

* Bug bounty: public program opens prior to production (pre-M4)

* Secrets and key material: no custodial control; user shares remain private; runners receive least-privilege, time-bound capabilities only

* Incident response: runbooks, on-chain pausability for critical conditions, post-incident reviews

### Data-backed assumptions (selected)

* BTC collateral utilization \~45% (consistent with MakerDAO-style ratios and BIS ranges of 120–150% collateralization)
* Liquidation stress reference: \~\$325M liquidations in 24h during the 2022 downturn (used for stress testing and fee modeling)

# Risk Analysis & Mitigation Strategy

## Risk Matrix

<Expandable title="View Risk Matrix and scoring">
  ### Technical risks

  * Integration complexity - 2PC‑MPC integration with Ika proves more complex than anticipated
    * Probability: Medium
    * Impact: High
    * Risk: High
    * Mitigation: Dedicated 2‑week integration sprint in Month 1; direct collaboration with Ika team; fallback to simplified MPC if needed
    * Owner: Lead Architect
  * Cross‑chain reliability - Network instability or consensus failures on Bitcoin/Ethereum/Solana
    * Probability: Medium
    * Impact: High
    * Risk: High
    * Mitigation: Multi‑node redundancy for each chain; circuit breakers for network issues; graceful degradation protocols
    * Owner: DevOps Engineer
  * Smart contract bugs - Critical vulnerabilities in lending contracts
    * Probability: Low
    * Impact: Very High
    * Risk: High
    * Mitigation: 3‑phase audit process (internal → external → formal verification); \$500K security budget; bug bounty program pre‑launch
    * Owner: Security Engineer
  * Oracle manipulation - Price feed manipulation or oracle failures
    * Probability: Medium
    * Impact: High
    * Risk: High
    * Mitigation: Multiple oracle sources (Pyth + backup); price deviation monitoring; emergency pause mechanisms
    * Owner: DeFi Engineer

  ### Regulatory risks

  * Regulatory crackdown - Major jurisdiction bans cross‑chain lending
    * Probability: Low
    * Impact: Very High
    * Risk: High
    * Mitigation: Multi‑jurisdiction legal structure; \$200K compliance + \$200K legal budget; regulatory sandbox participation
    * Owner: Legal Team
  * Securities classification - Tokens classified as securities requiring registration
    * Probability: Medium
    * Impact: High
    * Risk: High
    * Mitigation: Legal opinions on token structure; utility‑focused token design; compliance‑first approach
    * Owner: Legal Team
  * AML/KYC requirements - Mandatory KYC implementation required
    * Probability: High
    * Impact: Medium
    * Risk: Medium
    * Mitigation: Modular, counterparty‑driven KYC/KYB for P2P; attestation‑based (no PII on‑chain); jurisdiction/threshold‑based enforcement
    * Owner: Compliance Officer

  ### Market risks

  * Low adoption - Users don’t adopt cross‑chain lending
    * Probability: Medium
    * Impact: High
    * Risk: High
    * Mitigation: Extensive user research and testing; incentives for early adopters; partnerships with major DeFi protocols
    * Owner: Product Manager
  * Competitive response - Major DeFi protocols launch competing solutions
    * Probability: High
    * Impact: Medium
    * Risk: Medium
    * Mitigation: First‑mover advantage execution; protective IP where possible; continuous innovation roadmap
    * Owner: CEO
  * Market volatility - Crypto market crash affects funding/adoption
    * Probability: Medium
    * Impact: Medium
    * Risk: Medium
    * Mitigation: Conservative treasury management; diversified funding sources; bear‑market product‑market fit
    * Owner: CFO

  ### Operational risks

  * Key personnel loss - Critical team members leave during development
    * Probability: Medium
    * Impact: High
    * Risk: High
    * Mitigation: Competitive compensation packages; knowledge documentation; cross‑training initiatives
    * Owner: HR Manager
  * Funding shortfall - Additional funding needed beyond seed grant
    * Probability: Low
    * Impact: High
    * Risk: Medium
    * Mitigation: Detailed budget monitoring; milestone‑based funding releases; Series A preparation
    * Owner: CFO
  * Timeline delays - Development takes longer than 16 months
    * Probability: Medium
    * Impact: Medium
    * Risk: Medium
    * Mitigation: Agile development methodology; regular milestone reviews; scope adjustment protocols
    * Owner: Project Manager

  ### Risk scoring (legend)

  * Low Impact + Low Probability → Low
  * Medium combinations → Medium
  * High Impact + Medium/High Probability → High
</Expandable>

## Regulatory Engagement Plan (P2P)

* Frameworks to monitor: FinCEN/BSA + Travel Rule (US), MiCA (EU), PSA (SG); local VASP/MSB definitions by deployment.
* P2P stance: Counterparty‑driven KYC/KYB; small, crypto‑only bilateral loans can be non‑KYC where permitted by law.
* Technical approach: Attestation‑based KYC (pass/fail) via Nautilus TEEs on Sui; Seal for encrypted data access; no PII on‑chain.
* Supervised access: Establish legal pathway for regulators to subpoena underlying PII from the KYC provider if legally compelled.
* Travel Rule readiness: Exchange beneficiary info when interacting with VASPs/fiat rails above thresholds; log audit events on Sui.
* Geo‑controls: Block restricted jurisdictions; per‑deployment policy toggles; threshold‑based enforcement (amounts, roles, assets).
* Documentation: Position paper on non‑custodial P2P marketplace operator scope and control boundaries; counsel review pre‑M3.

## Interim Owner Assignments (until hiring completes)

* CEO → Lead Architect (interim)
* CFO → Lead Architect (interim) with external accounting support
* HR Manager → Talent Acquisition lead
* Product Manager → Frontend/UX Lead with Lead Architect support
* Legal Team, Compliance Officer → external partners until in-house roles are filled

# Key Performance Indicators (KPIs) & Success Metrics

<Tip>
  Public dashboard (testnet→mainnet): collateralization ratios, liquidations, inclusion times, fees, and health factor distributions. URL TBD; publish raw datasets and methodology monthly.
</Tip>

## Overall Project Success Metrics

<Expandable title="View full metrics table">
  | Metric Category            | Target                              | Measurement Method     | Success Threshold        |
  | -------------------------- | ----------------------------------- | ---------------------- | ------------------------ |
  | **Technical Performance**  |                                     |                        |                          |
  | Protocol Uptime            | 99.9%                               | Automated monitoring   | >99.5% acceptable        |
  | Transaction Success Rate   | 99.5%                               | On-chain analytics     | >99% acceptable          |
  | Cross-Chain Action Latency | Submit/broadcast \<30s (all chains) | Performance monitoring | \<60s acceptable         |
  | Bitcoin Confirmation Time  | Median 1 conf \<= 12 min            | Chain analytics        | \<= 20 min acceptable    |
  | Ethereum Inclusion Time    | Median inclusion \<= 30s            | Chain analytics        | \<= 60s acceptable       |
  | Solana Inclusion Time      | Median inclusion \<= 3s             | Chain analytics        | \<= 5s acceptable        |
  | **Security & Compliance**  |                                     |                        |                          |
  | Security Audit Score       | 0 critical vulnerabilities          | External audit reports | 0 critical, \<3 high     |
  | Regulatory Compliance      | 100% compliant operations           | Legal review           | Full compliance required |
  | **Market Adoption**        |                                     |                        |                          |
  | Total Value Locked (TVL)   | \$10M+ at launch                    | On-chain data          | \$5M minimum acceptable  |
  | Active Users               | 1,000+ monthly                      | Analytics dashboard    | 500+ minimum acceptable  |
  | **Financial Performance**  |                                     |                        |                          |
  | Budget Adherence           | Within 5% of budget                 | Financial tracking     | Within 10% acceptable    |
  | Revenue Generation         | \$50K+ monthly fees                 | Protocol analytics     | \$25K+ acceptable        |
</Expandable>

## Milestone-Specific KPIs

<Expandable title="View Milestone-specific KPI tables">
  ### Core Protocol Foundation (6 months)

  **Success Criteria**: Functional cross-chain lending on Sui testnet with BTC-USDC lending pairs

  | KPI                       | Target                         | Measurement          | Success Threshold            |
  | ------------------------- | ------------------------------ | -------------------- | ---------------------------- |
  | Smart Contract Deployment | 100% core contracts deployed   | Testnet verification | All contracts functional     |
  | Health Factor Accuracy    | \<1% calculation error         | Automated testing    | \<2% acceptable              |
  | Oracle Integration        | 99.9% uptime                   | Monitoring dashboard | >99% acceptable              |
  | Relayer Network           | 100% transaction relay success | Network monitoring   | >95% acceptable              |
  | Team Hiring               | 100% positions filled          | HR tracking          | >80% acceptable              |
  | Security Review           | 0 critical vulnerabilities     | Internal audit       | \<3 high severity acceptable |
  | **Budget**: \$1,100,000   | Within budget                  | Financial tracking   | Within 10% acceptable        |

  ### Cross-Chain Integration (4 months)

  **Success Criteria**: Multi-chain testnet with BTC-USDC, ETH-USDC, and SOL-USDC lending pairs

  | KPI                      | Target                           | Measurement            | Success Threshold     |
  | ------------------------ | -------------------------------- | ---------------------- | --------------------- |
  | Multi-Chain Support      | 3 chains fully integrated        | Technical verification | 2+ chains acceptable  |
  | Cross-Chain Transactions | 100 successful test transactions | Transaction logs       | 50+ acceptable        |
  | Keeper Network Uptime    | 99.5% operational                | Network monitoring     | >95% acceptable       |
  | UI/UX Completion         | 100% multi-chain interface       | Design review          | >90% acceptable       |
  | Community Engagement     | 500+ Discord/Telegram members    | Social metrics         | 250+ acceptable       |
  | Integration Testing      | 95% test coverage                | Automated testing      | >85% acceptable       |
  | **Budget**: \$700,000    | Within budget                    | Financial tracking     | Within 10% acceptable |

  ### Advanced Features & Security (4 months)

  **Success Criteria**: Audit-ready protocol with institutional-grade security & advanced risk management

  | KPI                      | Target                                              | Measurement            | Success Threshold          |
  | ------------------------ | --------------------------------------------------- | ---------------------- | -------------------------- |
  | Risk Analytics           | 100% risk metrics implemented                       | Feature verification   | >90% acceptable            |
  | Security Audit Results   | 0 critical, \<5 high severity                       | External audit reports | 0 critical, \<10 high      |
  | Formal Verification      | Core safety-critical contracts verified             | Verification reports   | >80% core scope acceptable |
  | Performance Optimization | \<10s protocol orchestration (excl. chain finality) | Performance testing    | \<30s acceptable           |
  | Documentation            | 100% technical docs complete                        | Documentation review   | >90% acceptable            |
  | Stress Testing           | Handle 1000+ concurrent users                       | Load testing           | 500+ acceptable            |
  | **Budget**: \$550,000    | Within budget                                       | Financial tracking     | Within 10% acceptable      |

  ### Production Deployment (2 months)

  **Success Criteria**: Live protocol with \$10M+ initial TVL

  | KPI                   | Target                     | Measurement          | Success Threshold        |
  | --------------------- | -------------------------- | -------------------- | ------------------------ |
  | Mainnet Deployment    | 100% successful deployment | Network verification | Full deployment required |
  | Initial TVL           | \$10M+ within 30 days      | On-chain analytics   | \$5M+ acceptable         |
  | User Onboarding       | 1000+ active users         | User analytics       | 500+ acceptable          |
  | Transaction Volume    | \$1M+ daily volume         | Protocol analytics   | \$500K+ acceptable       |
  | Community Growth      | 2000+ community members    | Social metrics       | 1000+ acceptable         |
  | Media Coverage        | 10+ major publications     | PR tracking          | 5+ acceptable            |
  | **Budget**: \$150,000 | Within budget              | Financial tracking   | Within 10% acceptable    |
</Expandable>

## Continuous Monitoring KPIs

### Technical Health

* **System Uptime**: 99.9% target (measured hourly)
* **Response Time**: \<2 seconds API response (measured continuously)
* **Error Rate**: \<0.1% transaction failures (measured daily)

### Security Metrics

* **Vulnerability Response**: \<24 hours for critical issues
* **Incident Resolution**: \<4 hours for system issues
* **Security Score**: Maintain A+ rating on security dashboards

### Business Metrics

* **User Growth**: 20% month-over-month growth
* **TVL Growth**: 15% month-over-month growth
* **Revenue Growth**: 25% month-over-month growth

### Community Metrics

* **Community Engagement**: 70%+ active community members
* **Developer Adoption**: 50+ developers building on protocol
* **Partnership Growth**: 5+ strategic partnerships per quarter

## Success Measurement Framework

### Data Collection

* **Automated Monitoring**: Real-time dashboards for technical metrics

### Revenue Scenarios (Illustrative)

* Assumptions (Base): \$10M TVL at launch; 45% utilization; avg loan duration 60 days; origination fee 0.2%; protocol interest share 5% of interest; 0.05% execution fee on liquidations (2% annualized liquidation volume).

* Conservative: \$5M TVL, 30% utilization → \~\$30–45K annualized gross fees.

* Base: \$10M TVL, 45% utilization → \~\$120–180K annualized gross fees.

* Aggressive: \$25M TVL, 55% utilization → \~\$400–600K annualized gross fees.

* Notes: Fees exclude enterprise SLAs/APIs; BTC/EVM/SOL relay costs modeled in infra budget; unit economics improve with automation.

* **Manual Reviews**: Weekly team assessments and milestone reviews

* **External Validation**: Monthly third-party performance audits

### Reporting Schedule

* **Daily**: Technical health and security metrics
* **Weekly**: Progress against milestone KPIs
* **Monthly**: Comprehensive performance review
* **Quarterly**: Strategic goal assessment and adjustment

### Escalation Procedures

* **Yellow Alert**: KPI falls below success threshold
* **Red Alert**: KPI falls below acceptable threshold
* **Emergency Protocol**: Critical system or security issues

## Risk-Adjusted Success Criteria

### Minimum Viable Success

If facing significant challenges, minimum acceptable outcomes:

* **Technical**: 2+ chains operational with basic lending
* **Security**: 0 critical vulnerabilities, external audit passed
* **Market**: \$2M+ TVL with 200+ active users
* **Financial**: Project completed within 120% of budget

### Stretch Goals

If execution exceeds expectations:

* **Technical**: 5+ chains with advanced features
* **Security**: Formal verification of 100% contracts
* **Market**: \$25M+ TVL with 2500+ active users
* **Financial**: Project completed under budget with surplus

# Other Funding & Long-Term Vision

<Note>
  Post‑RFP planning disclaimer: The long‑term vision and funding plan are provisional and will evolve with findings from RFP execution, market feedback, and regulatory guidance.
</Note>

* Funding Plan:
  * Post‑RFP we plan a Series A of \$12–18M within 3–6 months of achieving testnet KPIs (BTC–USDC live, audit readiness).
  * Optional bridge (\$3–5M SAFE) contingent on traction to accelerate integrations.
  * Non‑dilutive: pursue ecosystem grants/partnerships (e.g., Sui, oracle providers, cross-chain protocols) for infra and research.

* Use of Proceeds (Series A):
  * Engineering (protocol, cross‑chain integrations, security): \~45–55%
  * Infrastructure/DevOps & Observability: \~10–15%
  * Security (audits, formal verification, bug bounty): \~10–15%
  * Compliance/Legal & Enterprise BD: \~10–15%

### P2P Fee Touchpoints (summary)

* Origination (borrower): 10–30 bps of draw; tiered by loan size/risk.

* Execution (liquidation): relayer execution fee reimbursed from penalty; protocol share aligns incentives.

* Optional enterprise: SLAs for private relayer, premium analytics/APIs.

  * Working capital & runway buffer: \~10%

* Monetization Model:
  * Protocol fees: 0.1–0.3% loan origination; small share of interest; execution fee on pre‑signed liquidation relays.
  * Enterprise: private relayer SLAs, premium analytics/APIs, support tiers.
  * Open‑core + proprietary: smart contracts/runners OSS; Frontend and Backend remain closed‑source with commercial licensing.

## Fee Model & Flows

### Components and Defaults

* Origination fee: 0.20% of draw (range 0.10–0.30%)
* Reserve factor: 10% of interest to reserves (60% Insurance, 40% Treasury)
* Liquidation penalty: 7% of repaid debt at liquidation (50% Insurance, 30% Relayer, 20% Treasury)
* Relayer execution fee: USDC‑denominated reimbursement priced from on‑chain gas with safety multiplier 1.15× and per‑action caps (chain‑specific)
* Deposit/withdraw/early‑repay: 0

### Who pays and when

* Borrower on draw: pays origination fee immediately; receives net draw or mints slightly more debt for net‑parity
* During operation: only interest; reserve factor skimmed to reserves
* On liquidation: borrower pays penalty; relayer reimbursed out of penalty; Insurance covers shortfalls, excess split per schedule

### Accounting and denomination

* Fees and reserves denominated in the debt asset on Sui (e.g., USDC)
* Cross‑chain gas paid by relayer in native asset; reimbursed in USDC using oracle FX at execution with safety multiplier and caps
* Insurance Fund maintains targets for shortfall coverage; governance can tune parameters within bounds

### Borrow fee flow (simplified)

```mermaid theme={null}
flowchart LR
  U[User] -->|Borrow| P[Protocol]
  P -->|Origination fee| T[Treasury]
  P -->|Reserve on interest| RF[Reserves]
```

### Liquidation fee flow (simplified)

```mermaid theme={null}
flowchart LR
  B[Borrower] -->|Penalty| Split[Penalty Fee Split]
  Split -->|Relayer reimbursement| R[Relayer]
  Split --> Insurance[Insurance Fund]
  Split --> T[Treasury]
```

### Parameterization

* Governed per market/chain: f\_orig, reserve\_factor, penalty, splits, exec fee base/variable/markup, safety multiplier, caps, insurance targets

* Change policy: governance‑controlled with bounded ranges and notice periods; emergency changes subject to on‑chain pause/rollback procedures

* Events: BorrowFee, InterestReserveAccrued, LiquidationPenalty, RelayerExecReimbursed, InsuranceTopUp

* Go‑to‑Market (GTM):
  * Phase 1 (Crypto‑native): BTC collateral \<-> stablecoin loans; incentives via fee rebates; targeted market makers.
  * Phase 2 (Protocol integrations): SDKs for wallets/DeFi protocols, co‑marketing with partners.
  * Phase 3 (Institutional): SLAs, compliance modules, custody integrations.

```mermaid theme={null}
timeline
  title Go-to-Market (GTM) Phases
  Q0 (Post-RFP): Achieve testnet KPIs (BTC–USDC live, audit readiness)
  Q1–Q2: Phase 1 - Crypto-native
    : BTC collateral <-> stablecoin loans
    : Fee rebates, targeted market makers
  Q3–Q4: Phase 2 - Protocol integrations
    : SDKs for wallets/DeFi protocols
    : Co-marketing with partners
  Q5–Q6: Phase 3 - Institutional
    : SLAs, compliance modules, custody integrations
    : Enterprise BD, initial contracts
```

* Long‑Term Vision (24–36 months):
  * 20+ assets across 8+ chains; portfolio‑level collateral (entire dWallets), privacy‑preserving compliance (e.g., ZK‑KYC attestations).
  * Progressive decentralization of governance and operations; community‑driven risk frameworks.

* Traction Targets:
  * Year 1: \$100M TVL across 4 chains; 10k MAU; \$1.5–3.0M annualized fee run‑rate.
  * Year 2: \$250M TVL; 25k MAU; \$5–8M ARR; enterprise contracts signed.
  * Year 3: \$1B TVL; institutional adoption; sustainable positive unit economics.

* Token & Governance:
  * No token until PMF and audit‑ready status; then governance token to decentralize parameters/treasury.
  * Compliance‑first design; potential fee‑share and stewardship mechanisms subject to legal review.

* Future Deliverables:
  * SDKs and integration guides (public), threat model & formal verification reports, operational runbooks (relayer/keeper/IR),
    governance & community documentation, enterprise integration playbooks.

# Will your project be open source?

<Columns cols={3}>
  <Card title="Sui Contracts" icon="code-branch">Apache-2.0</Card>
  <Card title="Oracle Runner" icon="server">MIT</Card>
  <Card title="Keeper Runner" icon="server">MIT</Card>
  <Card title="Relayer Runner" icon="truck-fast">MIT</Card>
  <Card title="Frontend UI" icon="window-maximize">Closed source</Card>
  <Card title="Backend API" icon="gear">Closed source</Card>
  <Card title="Documentation" icon="book">CC BY 4.0</Card>
</Columns>

Subject to final alignment with client and partners.

## FAQ

<Expandable title="What is the custody model?">
  Users control their assets in their MPC dWallets. The protocol holds the position‑scoped, time‑bound DWalletCap; it is never shared with users, relayers, keepers, or any external wallet. Users/keepers express intents; the protocol evaluates on‑chain invariants and, if satisfied, uses its DWalletCap to authorize only the allowed action.
</Expandable>

<Expandable title="What is a DWalletCap and what are its limits?">
  DWalletCap is a protocol‑held capability that can sign only whitelisted, parameter‑bounded transaction templates (e.g., repay, liquidation) for a specific dWallet/position. It includes expiry and nonce, cannot sign arbitrary transfers, is non‑transferable, and acts as a programmable guardrail for actions borrowers/lenders can activate.
</Expandable>

<Expandable title="How do cross‑chain actions execute end‑to‑end?">
  Borrower/lender fund their MPC dWallets on source chains. On Sui, a user triggers an action; the protocol checks collateral/funds, price guardrails, and position state. If all checks pass, the protocol uses its DWalletCap to finalize the pre‑signed transaction and instructs the relayer to broadcast. The relayer never holds capabilities. Accounting settles on Sui (e.g., USDC on Sui in M1).
</Expandable>

<Expandable title="How are safety checks enforced?">
  On‑chain Move modules verify capability scope + expiry + nonce, position constraints, and oracle conditions before any use of the protocol‑held DWalletCap. Failing checks block execution; the cap remains bound by time/nonce and cannot authorize off‑scope actions.
</Expandable>

<Expandable title="What if oracles fail or data is degraded?">
  Safety over liveness: operations that require prices/confirmations pause; no signing occurs. Caps expire and must be renewed via governance/process. In M1, limited manual confirmation paths are acceptable; production uses multi‑source oracles and deviation thresholds.
</Expandable>

<Expandable title="How does liquidation work? Who can trigger it?">
  The Keeper (or anyone) can signal a liquidation condition on Sui. The protocol validates health factor and invariants, then uses its DWalletCap to sign the pre‑approved liquidation transaction within scope. The relayer broadcasts; settlement and distribution occur per the on‑chain schedule. No external party ever receives the capability.
</Expandable>

<Expandable title="How do expiry, rotation, and replay protection work?">
  Caps are time‑boxed and nonce‑scoped. The protocol records usage and rejects expired/already‑used envelopes; repeated submissions are idempotent or invalid. Since the cap is protocol‑held and non‑transferable, there is no “return” step-only expiry/rotation under protocol control.
</Expandable>

<Expandable title="What data is on Sui vs off‑chain runners?">
  Sui stores position state, capability metadata, and audit events. Off‑chain runners (relayer/oracle) never hold custody or capabilities; they submit transactions or attest confirmations only.
</Expandable>

<Expandable title="Which networks are supported in M1 vs later?">
  M1 demo: BTC testnet collateral and Sui testnet USDC. Later milestones: Ethereum and Solana testnets, then mainnets post‑audit.
</Expandable>

<Expandable title="Do users need KYC? What is the compliance stance?">
  P2P model (no pools): compliance is modular and counterparty‑driven. Many markets still
  treat marketplace operators as VASPs/MSBs, so KYC/KYB may be required when (a) jurisdiction mandates it,
  (b) institutional lenders/borrowers participate, or (c) fiat rails/Travel Rule apply. Where permitted,
  small crypto‑only bilateral loans can be non‑KYC. We use attestation‑based proofs (pass/fail, not PII)
  via a third‑party provider; policy is configurable per deployment. On Sui, we can leverage Nautilus
  (TEE‑based verifiable off‑chain computation) to run private KYC/AML checks and submit
  attestations on‑chain for Move verification; optionally combine with Seal for encrypted data access
  to keep PII off‑chain. See: [https://blog.sui.io/nautilus-offchain-security-privacy-web3/](https://blog.sui.io/nautilus-offchain-security-privacy-web3/).
</Expandable>

## Glossary

<Expandable title="Key terms (quick reference)">
  * <strong>TTL (Time‑to‑live):</strong> A short validity window for an action or envelope. After TTL expiry, the protocol will not sign or execute the action.
    * Sui: enforced via <code>validUntil</code> checked in Move.
    * Solana: enforced implicitly by recent blockhash + lastValidBlockHeight (\~2 min).
    * EVM: enforced by a <code>deadline</code> field that the contract validates.
    * Bitcoin: enforced operationally (immediate broadcast) with Sui gating.

  * <strong>DKG (Distributed Key Generation):</strong> Key shares created without ever forming a full private key; no single party learns the full key.

  * <strong>t-of-n threshold:</strong> A signature is valid only when t partial signatures from n MPC nodes are combined; improves availability and fault tolerance.

  * <strong>Nonce:</strong> A one‑time sequence/identifier that prevents replay. Once consumed, repeated submissions are rejected or made idempotent.

  * <strong>DWalletCap:</strong> A protocol‑held, least‑privilege, time‑bound capability scoped to a specific dWallet/position and action (e.g., repay, liquidation). Non‑transferable; never shared with users, relayers, or keepers.

  * <strong>Scope (of a capability/envelope):</strong> The exact bounds under which an action is allowed: position/dWallet, action type, asset(s), amount limits, and any slippage/execution caps.

  * <strong>Presigned envelope:</strong> A parameter‑bounded transaction template (scope, amounts, assets, TTL, nonce) that the protocol finalizes with its DWalletCap only if on‑chain checks pass.

  * <strong>MPC dWallet:</strong> A user‑owned multi‑party computation wallet. Users retain control of key shares; the protocol never holds standing signing keys.

  * <strong>Keeper:</strong> Off‑chain watcher that signals conditions (e.g., liquidation). Never holds custody or capabilities.

  * <strong>Relayer:</strong> Off‑chain broadcaster that submits fully signed transactions and returns confirmations. Never holds custody or capabilities.

  * <strong>TEE (Trusted Execution Environment):</strong> Isolated, tamper‑resistant compute (e.g., AWS Nitro Enclaves) used to run private checks offchain and produce attestations.

  * <strong>Attestation (TEE):</strong> A cryptographic proof that specific code ran in a verified TEE with given inputs; Move contracts on Sui can verify it before acting.

  * <strong>Nautilus (Sui):</strong> A Sui framework for verifiable offchain privacy using TEEs; enables private KYC/AML oracles and onchain attestation verification. Docs: [https://blog.sui.io/nautilus-offchain-security-privacy-web3/](https://blog.sui.io/nautilus-offchain-security-privacy-web3/)

  * <strong>Seal (Sui):</strong> Decentralized encryption and programmable access control on Sui; can be paired with Nautilus to keep PII offchain and selectively reveal data.

  * <strong>Oracle:</strong> Data provider (e.g., prices, confirmations). Critical actions require healthy oracle conditions / deviation bounds.

  * <strong>Position:</strong> Borrower/lender state on Sui (collateral, debt, parameters, health factor) that gates allowed actions.

  * <strong>Health factor:</strong> A risk metric derived from collateral value, debt, and oracle prices; falling below threshold can trigger liquidation.
</Expandable>

## References

<Expandable title="References (selected)">
  * BIS collateralisation ranges; MakerDAO ratios: [BIS: DeFi lending: intermediation without information?](https://www.bis.org/publ/bisbull57.pdf); [MakerDAO Liquidation 2.0 Module](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation)
  * 2022 crash liquidation metrics: [CoinDesk: BTC rally triggers >\$300M in liquidations (Mar 29, 2022)](https://www.coindesk.com/markets/2022/03/29/bitcoin-nears-200-day-average-ahead-of-seasonally-bullish-period-triggers-over-400m-in-liquidations)
  * LayerZero DVN overview; THORChain overview: [LayerZero DVNs](https://docs.layerzero.network/v2/concepts/modular-security/security-stack-dvns); [THORChain Docs](https://docs.thorchain.org/)
  * Nautilus offchain privacy blog: [https://blog.sui.io/nautilus-offchain-security-privacy-web3/](https://blog.sui.io/nautilus-offchain-security-privacy-web3/)
  * Ika 2PC‑MPC technical docs: [https://ika.org/](https://ika.org/)
  * Pyth price feeds: [https://pyth.network/](https://pyth.network/)
  * Market data: [https://coinmarketcap.com/](https://coinmarketcap.com/)
</Expandable>

## Social Links

<Columns cols={3}>
  <Card title="GitHub" icon="link" href="https://github.com/inkwell-finance">Source code and organization</Card>
  <Card title="Website" icon="globe" href="https://inkwell.finance">[https://inkwell.finance](https://inkwell.finance)</Card>
  <Card title="Twitter" icon="link" href="https://twitter.com/__Inkwell">Follow updates</Card>
</Columns>