Security & Trust Model

How Inkwell reasons about security, trust, and risk across the cryptographic stack the products and services run on.

CONFIDENTIAL & PROPRIETARY © 2026 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 reasons about security and trust across the cryptographic stack our products and services run on — 2PC-MPC threshold signing (Ika), fully homomorphic encryption (Encrypt REFHE), and cross-chain verification.

It is not an audit report or a formal assurance statement. It is a guide to the design principles, assumptions, and threat model we apply across Leviathan, Dagon, Synthase, IKA Staking + LIKA, and the services we ship.

For a deeper read on what we centralise and why, see Design Philosophy.

Core principles

• Non-custodial by design

  • Users do not give Inkwell unilateral control over their assets.
  • Control is split between participants and protocol-enforced rules.
  • This is the one axis we do not compromise.

• Least-privilege signing

  • dWallets and contracts are scoped to specific actions (e.g. “liquidate this loan under these conditions” or “match orders in this batch under this circuit”).
  • 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, allowed destinations) live in smart contracts, not documents or off-chain scripts.

• Explicit end states

  • Loans, deals, matches, and transfers have clear completion conditions. Once an obligation is satisfied there are no hidden or perpetual rights.

• Tracked trust assumptions

  • Every load-bearing trust assumption — named attester, hosted indexer, operator-cranked matching — is documented with a migration path. See Design Philosophy.

Threat model (high-level)

Assumptions

• Solana follows its consensus and safety guarantees. Anchor programs depend on the Solana runtime for account validation, signer checks, and 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.
• Encrypt’s encrypt-program correctly implements REFHE programmable bootstrap and the on-chain ciphertext lifecycle as documented and audited separately. (Pre-alpha: ciphertexts are plaintext-shaped on-chain pending the Alpha-1 wipe.)
• Users, issuers, and counterparties take reasonable care of their own key material and infrastructure.

Threats we design against

• Single-operator custody. No architecture where a single company or multisig can move user or counterparty funds at will.
• Bridge-style lock-and-mint risk. Where cross-chain value moves, we prefer burn-and-mint with on-chain policy over long-lived locked pools controlled by opaque signers.
• Replay and double-spend. Policy contracts track consumed events and enforce replay protection for cross-chain flows and session-key actions.
• Unchecked parameter changes. Risk parameters (caps, limits, pause switches) are stored and updated through governed on-chain mechanisms.
• Hidden ongoing rights. Debt, marketplace, and matching structures terminate cleanly; counterparties do not retain unbounded or unclear claims.
• Front-running of confidential workloads. Matching engines and signing committees that handle pre-trade data run over ciphertexts — the operator is cryptographically blind to the inputs.

How the principles apply per product

Leviathan — revenue-backed credit

• Collateral & loan control. Loan funds are held in dWallet-controlled vaults. Sui contracts define when these vaults can move funds (activation, liquidation, repayment).
• Health & liquidation. Oracles and protocol rules monitor health factors. Liquidations only occur via predefined, auditable flows.
• Cross-chain verification. leviathan-verifier parses Solana and EVM transactions against policy before signing is permitted. Today this depends on a named attester for cross-chain state; the migration path to ZK light clients is documented in Design Philosophy.
• End-of-life. Debt has a fixed repayment cap and a clean terminal state. No equity, no perpetual revenue claim.

Dagon — confidential matching

• Cryptographic blindness. The matching engine operates over REFHE ciphertexts; the operator cannot see flow.
• Selective disclosure. Public-input disclosure is opt-in by design. The only disclosure surface is the user’s own balance view on withdrawal — and a two-party compelled-process composition is needed to compel that disclosure.
• Operator liveness, not integrity. A misbehaving operator can halt matching, not steal flow. Target end-state is a decentralised threshold-FHE committee — gated on Encrypt REFHE shipping production threshold decryption.
• Structural self-trade prevention. Self-trade prevention is enforced at the unified-owners vector, not as a post-hoc filter.

IKA Staking + LIKA — Sui staking infrastructure

• Non-custodial staking. Stake transactions are signed by the user’s wallet. The agent / allocation engine recommends; it cannot move stake without user authorisation.
• Off-chain analytics. Validator scoring and APY history use operator-run pipelines; the data is published transparently and the on-chain stake transactions are independently verifiable.

Services engagements

• Threat-model deliverable. Every services engagement includes an explicit threat model and a tracked-trust-assumption table delivered alongside the integration. Counterparties get the same honesty about what is and is not trustless that our products do.

Cross-cutting controls

Cross-chain transaction verification

leviathan-verifier 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 counterparties conform to policy constraints (instruction targets, accounts, parameters).
• EVM transaction parsing — decodes EVM calldata and validates that contract calls target whitelisted addresses and functions.
• Policy compliance enforcement — every counterparty action is checked against the active policy before signing is permitted. Non-compliant transactions are rejected at the verification layer, before reaching the dWallet signing flow.

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

Policy sandboxing

Funds operate within a policy sandbox — on-chain constraints that define exactly what the holder can and cannot do with deployed capital:

• Whitelisted destinations. Only pre-approved contracts and addresses can receive transactions signed by the policy-gated dWallet.
• Daily limits. Time-bounded caps prevent rapid extraction 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.

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

Session key security model

Session keys are scoped, ephemeral signing keys with built-in constraints:

• Time-bounded validity. Expired keys are rejected regardless of other conditions.
• Scope-limited authority. Each session key is authorised for specific operations only.
• Nonce tracking. Every action increments an on-chain nonce, preventing replay.
• Revocable. Session keys can be revoked by the protocol or lender if policy violations are detected.

Internal security review

An internal security audit was conducted across all Solana programs in the Leviathan 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 were identified, categorised by severity, and remediated. External audit is in progress for Leviathan and LIKA.

Specific audit findings and vulnerability details are not disclosed publicly. Partners and auditors can request detailed security documentation under NDA at [e-mail].

What this model does not guarantee

Even with these controls, some risks remain outside the protocol’s scope:

• Underlying chain failures or consensus attacks.
• Bugs in smart contracts, dWallet implementations, FHE programs, or oracles that escape audits and testing.
• Misconfiguration or operational failures in counterparty infrastructure.
• Regulatory or legal interpretations in specific jurisdictions.

Inkwell’s goal is to minimise 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.