Inkwell Architecture Overview

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 explains how Inkwell is put together technically and how P2P Lending, CCTP, and the Revenue Marketplace all sit on the same core rails. At a high level, Inkwell has three main layers:

• Control Plane on Sui – smart contracts that encode policy, loan lifecycles, and canonical state.
• Cross-Chain Execution Layer – Ika dWallets and chain-specific contracts/programs that actually move assets.
• Off-Chain Agents & SDKs – issuer/borrower/lender-facing services and libraries that orchestrate flows.

​

1. Control Plane on Sui

Sui is the source of truth for protocol state and policy:

• P2P Lending
  • Loan requests, offers, active loans, and liquidations are represented as Sui objects.
  • Contracts track collateral requirements, health factors, and repayment schedules.
• CCTP
  • A policy engine and registries live on Sui.
  • They store per-chain configuration (supported chains, dWallets, signing schemes, limits, fees) and enforce burn/mint rules.
• Revenue Marketplace
  • Deal listings and loan positions are Sui objects with explicit principal, repayment caps, and lifecycle states.
  • Caps and term logic are enforced at the contract level.

​

2. Cross-Chain Execution with dWallets

Inkwell relies on Ika’s 2PC-MPC “dWallets” to control assets on other chains without custodial bridges:

• A dWallet splits control between:
  • An issuer/user share (held by the borrower, lender, or issuer and their infrastructure).
  • A network share integrated with Sui contracts and Ika’s MPC network.
• A transaction (for example, moving collateral, minting on a destination chain) only goes through when both shares participate according to policy.

This pattern is used across products:

• P2P Lending – dWallets hold collateral and loan funds on external chains; Sui contracts decide when they can move.
• CCTP – per-chain dWallets hold mint authority or treasury keys; Sui policy contracts gate when mints or burns are allowed.
• Revenue Marketplace – where collateralized or cross-chain legs are involved, the same vault and dWallet patterns apply.

This gives us least-privilege, programmable control over cross-chain assets without centralizing keys.

​

3. Chain-Specific Programs & Contracts

On each supported chain, Inkwell integrates with lightweight components:

• Standard token contracts / programs (ERC-20, SPL, Sui Coin)
• Small helper contracts or programs that:
  • Receive deposits / burns for CCTP.
  • Interface with dWallets for loan collateral and settlement.

The goal is to keep per-chain logic minimal and auditable, and move most complexity into:

• Sui control-plane contracts, and
• The dWallet infrastructure that signs “just enough” to enforce those contracts.

​

4. Off-Chain Agents & SDKs

To avoid baking all off-chain logic into monolithic backends, Inkwell uses:

• Issuer / Protocol Agents
  • Lightweight services that watch chains for events (e.g., burns, loan status changes).
  • Call into Sui contracts to request approvals.
  • Submit signed transactions using dWallets on each chain.
• TypeScript SDKs
  • Wrap low-level blockchain calls into higher-level methods (e.g., “create loan request”, “initiate CCTP transfer”).
  • Used by frontends, agents, and integrators to build on top of Inkwell without re-implementing flows.

These components are replaceable: organizations can run their own agents while still relying on the same on-chain guarantees.

​

5. How Each Product Uses the Architecture

​

P2P Lending

• Sui contracts define loans, collateral rules, and liquidation logic.
• dWallets hold collateral and loan funds across chains.
• Frontends + SDKs help borrowers and lenders:
  • Create requests and offers.
  • Track loan state and health.
  • Trigger repayments and closures.

​

CCTP

• Sui hosts the policy engine, registries, and replay protection.
• dWallets hold per-chain mint authority or treasury keys.
• Chain programs handle burns and mints under Sui policy supervision.
• Issuer agents watch for burns, ask Sui for approval, and then complete mints on destination chains.

​

Revenue Marketplace

• Sui contracts define deals, repayment caps, and accounting.
• Optionally reuses P2P collateral vaults and dWallet patterns where deals are collateralized or cross-chain.
• Frontends + SDKs present standardized templates (e.g., 1.3x cap over 18 months) and track repayment progress.

​

6. Design Goals

Across all products, the architecture is optimized for:

• Non-custodial control – no single party holds full keys to user or issuer assets.
• On-chain policy, off-chain flexibility – Sui contracts define what is allowed; agents and SDKs define how flows are orchestrated.
• Auditability – critical invariants (caps, supply limits, replay protection) are enforced in code, not policy documents.
• Composable building blocks – P2P, CCTP, and the Revenue Marketplace can be combined or extended without redesigning the core rails.

​

Disclaimers

This is a high-level architecture description and not a complete specification or security review. Implementation details may evolve over time. Builders and integrators should always consult the latest contracts, SDKs, and audits before depending on specific behaviors.