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

Inkwell CCTP (Cross-Chain Transfer Protocol) is a decentralized mint / burn orchestration layer for real‑world assets (RWA). Instead of wrapped tokens or centralized attestation services, issuers get a single, programmable policy engine on Sui plus imported‑key dWallets from Ika. Users burn tokens on a source chain and receive a native mint on the destination chain, while the protocol enforces all supply, policy, and security rules on‑chain.

For RWA Issuers

  • One canonical policy engine on Sui to control mint / burn across all chains.
  • Keep your own keys (via imported-key dWallets) while enforcing rules in Move contracts.

For Users

  • Burn on source chain, mint on destination—no wrapped assets.
  • Familiar token interfaces (ERC‑20, SPL, Sui Coin) on each chain.

For the Ecosystem

  • Avoid trusted bridges and ad hoc multisigs.
  • Standardized, auditable flows for multi‑chain stablecoins and other RWAs.
Like Circle’s CCTP, Inkwell CCTP uses burn on source + mint on destination to preserve native tokens and avoid wrappers. The key difference is that attestation and authorization are enforced entirely on‑chain on Sui, using a policy engine and secure split‑key wallets (dWallets) from Ika, rather than a centralized attestation service.

​
How It Works (High Level)

At a user level, CCTP turns a cross‑chain transfer into a simple sequence:

​
1. Start on the source chain

  • The user chooses a source chain, a destination chain, the asset, and the amount they want to move.
  • They approve a transfer into the CCTP flow; their tokens are removed from circulation on the source chain so total supply stays consistent.

​
2. Policy checks in the middle

  • An issuer‑run service detects that a transfer has started and sends a proof of it to the CCTP policy contracts on Sui.
  • The policy engine verifies that:
    • The transfer really happened and hasn’t already been used.
    • The issuer’s rules are respected (which chains are allowed, limits, pause switches, fees, etc.).
    • The transfer fits within the issuer’s overall supply and risk settings.

​
3. Mint on the destination chain

  • Once approved, the system prepares a transaction to issue fresh tokens on the destination chain.
  • A shared “split‑key” wallet (dWallet) signs this transaction only if both the issuer and the Sui policy engine have approved it.
  • The user receives native tokens on the destination chain; no wrapped assets are created at any point.

​
4. Optional fees

  • Issuers can optionally charge a very small fee (up to 0.01% per transfer).
  • Most of this fee goes to the issuer, with a small share reserved for the Inkwell protocol.

​
Architecture at a Glance

You can think of CCTP as four cooperating pieces:
  • Policy engine on Sui
    • Acts as the “control center” for all cross‑chain transfers.
    • Stores per‑chain settings, limits, and fee configuration, and decides when a transfer is allowed to go through.
  • Programs and contracts on each chain
    • Standard token contracts or small helper programs on Ethereum‑style chains, Solana, and Sui.
    • Their job is to start a transfer on the source chain and complete it on the destination chain, under the policy engine’s control.
  • Shared dWallets (split‑key wallets)
    • Special wallets that hold part of the issuer’s signing key, while the issuer keeps the other part.
    • A cross‑chain mint only happens when both sides participate, so neither the issuer nor the network can act alone.
  • Issuer agent & SDK
    • A lightweight service that issuers run to watch for transfers, talk to the Sui policy engine, and relay signed transactions to each chain.
    • A TypeScript SDK wraps these flows so integrators can use simple, high‑level methods instead of dealing with raw blockchain details.

​
Design Principles & Safeguards

  • Native assets, no wrappers – users always interact with standard token contracts on each chain.
  • On‑chain, deterministic policy – all mint / burn authorization is encoded in Move contracts on Sui, not in off‑chain attesters.
  • Replay protection by default – each transfer can only be completed once; repeated attempts are automatically rejected.
  • Per‑chain cryptography – CCTP uses the right signing scheme for each chain instead of forcing a one‑size‑fits‑all approach.
  • Operational separation – issuers control their environment (HSMs, infra) via the agent, while the protocol enforces non‑bypassable policy on‑chain.

​
What CCTP Is (and Is Not)

CCTP is infrastructure for multi‑chain RWA issuance, not a token or investment product itself.
  • It standardizes how issuers move supply between chains via burn‑and‑mint, with clear on‑chain rules.
  • It does not dictate the regulatory classification of any given RWA; issuers remain responsible for compliance.
  • It is designed so that security properties (no custodial bridges, no centralized attesters, explicit replay protection) are auditable in code, not enforced by trust.

​
Disclaimers

This overview describes the intended design of Inkwell CCTP and does not constitute legal, tax, or investment advice. Regulatory treatment of any particular RWA or issuance program depends on facts, circumstances, and jurisdiction. Issuers, integrators, and users should consult their own counsel and advisors before relying on this protocol as part of a regulated product or offering.