Skip to main content
CONFIDENTIAL & PROPRIETARY © 2025 Inkwell Finance, Inc. All Rights Reserved. This document is for informational purposes only and does not constitute legal, tax, or investment advice, nor an offer to sell or a solicitation to buy any security or other financial instrument. Any examples, structures, or flows described here are design intent only and may change.

​
Overview

This page describes how Inkwell thinks about security and trust across P2P Lending, CCTP, and the Revenue Marketplace. It is not an audit report or a formal assurance statement, but a guide to our design principles, assumptions, and the kinds of risks we aim to reduce.

​
Core Principles

  • Non-custodial by design
    • Users and issuers do not give Inkwell unilateral control over their assets.
    • Control is split between participants and protocol-enforced rules.
  • Least-privilege signing
    • dWallets and contracts are scoped to specific actions (e.g., “liquidate this loan under these conditions” or “mint up to X on chain Y”).
    • We avoid general-purpose keys or multisigs that can do “anything” with an address.
  • On-chain, deterministic policy
    • Critical rules (caps, limits, replay protection, allowed chains) live in smart contracts, not documents or off-chain scripts.
  • Explicit end states
    • Loans, deals, and transfers have clear completion conditions.
    • Once a loan is repaid or a transfer is finalized, there are no hidden or perpetual rights.

​
Threat Model (High-Level)

This section sketches what we assume and what we defend against.

​
Assumptions

  • Underlying chains (Sui, Solana, EVM chains, Bitcoin) follow their consensus and safety guarantees.
  • Ika’s dWallet infrastructure correctly implements 2PC-MPC and key management, as documented and audited separately.
  • Users, issuers, and agents take reasonable care of their own key material and infrastructure.

​
Threats We Design Against

  • Single-operator custody
    • We avoid architectures where a single company or multisig can move user or issuer funds at will.
  • Bridge-style lock-and-mint risk
    • CCTP uses burn-and-mint with on-chain policy, rather than long-lived locked pools controlled by opaque signers.
  • Replay and double-spend of messages
    • Policy contracts track consumed events and enforce replay protection for cross-chain flows.
  • Unchecked parameter changes
    • Risk parameters (caps, limits, pause switches) are stored and updated through governed on-chain mechanisms.
  • Hidden ongoing rights
    • Debt and marketplace structures are designed to terminate cleanly; lenders do not retain unbounded or unclear claims.

​
Product-Specific Notes

​
P2P Lending

  • Collateral & loan control
    • Collateral and loan funds are held in dWallet-controlled vaults.
    • Sui contracts define when these vaults can move funds (e.g., activation, liquidation, repayment).
  • Health & liquidation
    • Oracles and protocol rules monitor health factors.
    • Liquidations can only occur via predefined, auditable flows.
  • User obligations
    • Borrowers remain responsible for managing their own risk (e.g., posting and maintaining collateral). The protocol enforces rules but does not guarantee outcomes.

​
CCTP

  • Policy engine as gatekeeper
    • Every cross-chain mint must pass Sui policy checks (eligibility, limits, replay protection, fee rules).
  • Per-chain dWallets
    • Mint authority is split between issuer-operated infrastructure and the protocol’s network share.
    • Neither side can mint alone; both must participate under policy.
  • Native assets, no wrappers
    • Users interact with standard token contracts on each chain, reducing the attack surface associated with synthetic or wrapped assets.

​
Revenue Marketplace

  • Debt, not equity or perpetual revenue
    • The protocol enforces fixed repayment caps and end-of-life states for each loan.
  • Transparency of state
    • Loan status, amounts repaid, and remaining obligations are visible on-chain.
  • Use of data
    • Revenue data informs underwriting and payment sizing within caps; it does not grant lenders ownership of future revenue streams.

​
What This Model Does Not Guarantee

Even with these controls, some risks remain outside the protocol’s scope, including:
  • Underlying chain failures or consensus attacks.
  • Bugs in smart contracts, dWallet implementations, or oracles that escape audits and testing.
  • Misconfiguration or operational failures in issuer or user infrastructure.
  • Regulatory or legal interpretations in specific jurisdictions.
Inkwell’s goal is to minimize avoidable trust assumptions and make residual risk as explicit and auditable as possible, not to eliminate all risk.

​
Disclaimers

This page is not a substitute for formal security audits, legal review, or risk assessments. It is a high-level description of design intent.
  • Implementation details may change; always refer to current contracts, audits, and documentation.
  • Participants should perform their own due diligence and consult independent experts before relying on Inkwell’s protocols in production.