> ## Documentation Index
> Fetch the complete documentation index at: https://docs.inkwell.finance/llms.txt
> Use this file to discover all available pages before exploring further.

# CCTP Colosseum Hackathon Submission

> Summary of Inkwell CCTP submission to the Solana Colosseum hackathon.

> **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 summarizes Inkwell's **CCTP (Cross-Chain Transfer Protocol)** submission to the **Solana Colosseum hackathon**.

Inkwell CCTP is a **multi-chain RWA issuance orchestrator** that combines:

* A **policy engine on Sui** that encodes mint / burn rules for each supported chain.
* **Imported-key dWallets from Ika** so issuers keep their keys while sharing control with the Sui policy contracts.
* **Native burn-and-mint flows** on each chain (no wrapped assets), so supply is conserved and auditable.

The core idea: issuers get **Circle CCTP-style UX** without centralized attestation or custodial bridges, using Sui + Ika to enforce policy and signing.

## Submission Resources

* 🏆 **Colosseum project page**: [Inkwell Finance on Colosseum](https://arena.colosseum.org/projects/explore/inkwell-finance)
* 📊 **Pitch deck**: [Inkwell CCTP - Decentralized Multi-Chain RWA Issuance Platform](https://www.beautiful.ai/player/-OcqdIOL94gU92hkroU8/Inkwell-CCTP-Decentralized-Multi-Chain-RWA-Issuance-Platform)
* 🎥 **Pitch video**: [Inkwell CCTP Pitch Video](https://www.youtube.com/watch?v=5hoIZ6VfUvU)
* 🎥 **Demo video**: [Inkwell CCTP Demo Video](https://www.youtube.com/watch?v=svoZPHb9sFc)

## What We Showcased at Colosseum

The hackathon submission focused on demonstrating that **policy-driven, non-custodial cross-chain RWA issuance** is practical today.

Specifically, we showcased:

* **Sui policy engine prototypes**
  * Policy objects that store per-chain configuration (dWallets, token contracts, limits, fee settings).
  * Replay protection and per-transfer checks (caps, allow/deny lists, chain enablement).

* **dWallet-based authority model**
  * Imported-key dWallets where the issuer keeps the full private key (user share) and Sui policy contracts hold the network share.
  * Mint/burn transactions requiring dual participation: issuer + Sui policy engine.

* **Native burn-and-mint architecture**
  * Burn on the source chain, mint on the destination chain, with no wrapped tokens.
  * Standard token interfaces on each chain (ERC-20 / SPL / Sui Coin) to maximize compatibility.

* **Issuer agent & SDK concepts**
  * A lightweight issuer-run agent that watches burn events, talks to Sui, and submits destination-chain mints.
  * A TypeScript SDK design for integrating these flows into issuer infrastructure and wallets.

## Why It Matters for Solana, Sui, and RWA Issuers

For the hackathon, we framed CCTP as **infrastructure for multi-chain RWA issuance**, not a token product:

* **For Solana and Sui ecosystems**
  * Demonstrates a path to native, non-custodial cross-chain RWA flows without lock-and-mint bridges.
  * Uses Solana and Sui where they are strongest: high-performance execution (Solana) and safe on-chain policy (Sui Move).

* **For RWA issuers**
  * Single, auditable policy engine on Sui instead of per-chain ad hoc minting logic.
  * Issuer maintains custody and operational control while sharing enforcement with the network.
  * Burn-and-mint flows preserve native token semantics and simplify accounting.

* **For users and integrators**
  * Familiar token interfaces on each chain; no special "bridged" assets.
  * Clear, on-chain invariants: every destination-chain mint is backed by a prior burn + Sui policy approval.

## Relationship to the Current CCTP Design

The current CCTP architecture described in the **Overview** and **Proposal** pages is a direct evolution of the Colosseum submission:

* The **policy registry**, **burn handler**, and **mint orchestrator** in the proposal formalize the concepts first prototyped for the hackathon.
* The use of **per-chain dWallets** and **per-chain signing schemes** (ECDSA for EVM/Bitcoin, EdDSA for Solana, etc.) grew out of our early exploration of security isolation for issuers.
* The focus on a **canonical ledger on Sui** with reconciliation and replay protection builds on lessons from the initial demo flows.

In other words, the Colosseum submission was the **first concrete end-to-end demo** of this architecture; the current RFP proposal generalizes and hardens it into a production-ready protocol.

## Next Steps

* Continue refining the Sui policy engine and per-chain integrations beyond the initial hackathon scope.
* Align the CCTP implementation with issuer feedback, security review, and Ika RFP requirements.
* Use the Colosseum materials (deck, videos, demo flows) as a reference for future ecosystem talks, RFPs, and documentation.