Security & Trust Model

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

• Solana follows its consensus and safety guarantees. Anchor programs depend on the Solana runtime for account validation, signer checks, and program-derived address (PDA) integrity.
• Sui follows its consensus and safety guarantees. Object ownership and capability-based access control are enforced by the Sui runtime.
• EVM chains follow their respective consensus guarantees. RevenueSplitter contracts depend on standard EVM execution semantics.
• 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.

​

Cross-Chain Transaction Verification

The leviathan-verifier program is a dedicated security component that parses and validates transactions across chains before they are executed:

• Solana transaction parsing — verifies that Solana transactions submitted by borrowers conform to policy constraints, checking instruction targets, accounts, and parameters against the approved set.
• EVM transaction parsing — decodes EVM calldata and validates that contract calls target whitelisted addresses and functions.
• Policy compliance enforcement — every borrower action is checked against the active policy before signing is permitted. Transactions that violate policy are rejected at the verification layer, before they reach the dWallet signing flow.

This creates a defense-in-depth boundary: even if a borrower constructs a malicious transaction, it must pass verification before the protocol will co-sign it.

​

Policy Sandboxing

Borrowed capital operates within a policy sandbox — a set of on-chain constraints that define exactly what the borrower can and cannot do with deployed funds:

• Whitelisted destinations — only pre-approved contracts and addresses can receive transactions signed by the policy-gated dWallet. Attempts to interact with non-whitelisted targets are rejected.
• Daily limits — time-bounded caps on transaction volume prevent rapid extraction of capital, even to approved destinations.
• Function-level controls — policies can restrict not just which contracts are callable, but which specific functions on those contracts are permitted. A borrower approved for trading may be restricted from withdrawal functions on the same protocol.

Policy parameters are set at loan origination and can only be modified through governed on-chain mechanisms. The borrower cannot unilaterally relax their own sandbox.

​

Session Key Security Model

To enable borrowers to operate efficiently within their policy sandbox, the protocol uses session keys — scoped, ephemeral signing keys with built-in security constraints:

• Time-bounded validity — session keys expire after a configured duration. Expired keys are rejected by the protocol regardless of other conditions.
• Scope-limited authority — each session key is authorized for specific operations only (e.g., trading on approved venues). It cannot be used for actions outside its defined scope.
• Nonce tracking — every session key action increments an on-chain nonce. This prevents replay attacks where a previously valid signed action is resubmitted.
• Revocable — session keys can be revoked by the protocol or lender if policy violations are detected, immediately cutting off the borrower’s ability to execute further actions.

Session keys allow borrowers to transact without requiring lender co-signing for every operation, while maintaining the security invariant that all actions stay within policy bounds.

​

Internal Security Review

An internal security audit was conducted across all Solana programs in the Leviathan protocol suite (leviathan-core, leviathan-pool, leviathan-score, leviathan-verifier). The review covered:

• Account validation and PDA derivation correctness
• Authority and signer checks across all instructions
• Arithmetic safety (overflow, underflow, precision loss)
• State machine integrity and lifecycle transitions
• Access control and privilege escalation vectors
• Cross-program invocation (CPI) safety

Findings from the review were identified, categorized by severity, and remediated. The protocol team maintains an ongoing practice of internal review as programs evolve.

​

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.