CONFIDENTIAL & PROPRIETARY - SOLICITED PROPOSAL © 2025 Inkwell Finance, Inc. All Rights Reserved. Commercial use, reproduction, or distribution prohibited without written agreement with Inkwell Finance, Inc.

​

Executive Summary

​

Pitch Video

​

Demo Video

​

Project Overview

​

Why This Product is Valuable

The multi-chain RWA ecosystem faces a fundamental coordination problem: liquidity fragmentation. When a stablecoin issuer like Circle wants to support Ethereum, Solana, and Polygon, they must deploy separate contracts on each chain with independent minting authorities. This creates three critical problems:

1. Trust Centralization: Traditional approaches use centralized attestation services (like Circle’s CCTP) or federated multisigs, creating censorship risk and single points of failure
2. Operational Complexity: Issuers must manage separate keys, monitor multiple chains, and manually reconcile global supply across fragmented systems
3. Impossible Trade-offs: Existing solutions force choices between security (centralized control), decentralization (economic trust in validators), and user experience (wrapped assets with bridge friction)

Our solution eliminates these trade-offs by combining three breakthrough technologies:

• Ika’s 2PC-MPC imported-key dWallets: The issuer retains their full private key (user share) while the Sui policy contract holds the network share. Both must co-sign every mint/burn, ensuring dual-participation control without custodial risk.
• Sui on-chain policy engine: All compliance rules (supply caps, allow/deny lists, jurisdiction gating) execute deterministically in Move contracts. No centralized attestation service can censor or delay transfers.
• Native burn-and-mint architecture: Like Circle’s CCTP, we avoid wrapped assets entirely. Tokens are burned on the source chain and natively minted on the destination chain, maintaining fungibility and eliminating bridge risk.

The value proposition is clear: RWA issuers get Circle-level UX with zero trust assumptions. A single policy contract on Sui orchestrates minting across all chains, while the issuer maintains full control through their key share. This unlocks multi-chain RWA issuance for stablecoins, tokenized treasuries, carbon credits, and even NFT-based assets like property titles—all without custodians, attestation services, or economic security assumptions.

​

How We Plan to Build the Features That Matter Most

Our implementation strategy prioritizes security isolation, deterministic policy enforcement, and developer ergonomics through a layered architecture:

​

1. Sui Policy Engine (Core Orchestration Layer)

The heart of the system is a set of Move contracts on Sui that serve as the single source of truth for all cross-chain minting:

• Policy Registry: Each issuer creates a policy object containing per-chain configurations (dWallet references, contract addresses, supply caps, signing parameters), global compliance rules (allow/deny lists, pause controls), and canonical supply tracking across all chains.
• Burn Handler: Implements a secure two-step burn flow where users first deposit tokens into escrow, then the issuer agent burns them and submits proof to Sui while paying a small protocol fee.
• Mint Orchestrator: Validates the burn proof, checks all policy rules (supply caps, enabled status, replay protection), constructs the destination chain transaction, and requests an Ika signature to authorize the mint.

Why this approach: By centralizing policy logic on Sui, we achieve deterministic, auditable enforcement. The issuer cannot bypass rules (the policy contract must approve), and no external party can censor (the issuer must co-sign). Sui’s parallel execution handles high throughput, and Move’s type safety prevents common smart contract vulnerabilities.

​

2. Per-Chain dWallet Architecture (Security Isolation)

Instead of one dWallet controlling all chains, we create separate imported-key dWallets per destination chain—one for Bitcoin, one for Ethereum/EVM chains, and one for Solana. Each uses the appropriate cryptographic scheme for that ecosystem. Why this approach: Security isolation limits blast radius—a compromised Ethereum key doesn’t affect Solana. It also supports existing tokens with different mint authorities. The trade-off is operational complexity (managing multiple dWallets), but we mitigate this with SDK abstractions and automated key rotation tooling.

​

3. Chain-Specific Contracts (Native Integration)

We deploy native burn/mint contracts on each supported chain:

• Solana: We migrated from Anchor to the Pinocchio framework, achieving 88-95% compute unit reduction and 40% smaller binary size. The program handles token deposits, burns, and mints with Ed25519 signature verification.
• EVM (Ethereum, Polygon, etc.): Standard ERC-20 contracts with burn and mint functions. The minter role is assigned to the Ethereum dWallet address, and we verify Ika signatures on-chain before minting.
• Sui: Native coin integration using Sui’s treasury capability system. The issuer agent directly burns and mints tokens—no additional contract needed thanks to Sui’s elegant object model.

Why this approach: Native contracts avoid wrapped assets and bridge friction. Users interact with standard token interfaces (ERC-20, SPL Token, Sui Coin), ensuring compatibility with existing wallets, DEXs, and dApps. The Pinocchio migration demonstrates our commitment to performance—we’re not just building a proof-of-concept, but production-grade infrastructure.

​

4. Issuer Agent (Off-Chain Orchestration)

The issuer runs a lightweight Node.js agent that monitors burn events across all chains, completes the burn process, submits attestations to Sui, requests signatures from Ika, and broadcasts mint transactions to destination chains. The agent is stateless and event-driven—it doesn’t store private keys (those are in the issuer’s HSM) or maintain complex state. It simply reacts to on-chain events and coordinates the multi-step flow. Why this approach: Separating orchestration from policy enforcement allows issuers to customize their operational setup (cloud vs. on-prem, HSM integration, multi-region redundancy) while the Sui contracts enforce immutable rules. The agent is open-source (MIT license) so issuers can audit, fork, or self-host.

​

5. TypeScript SDK (Developer Ergonomics)

We provide a clean TypeScript SDK that abstracts all the complexity of interacting with Move contracts, building transactions, and coordinating with Ika. Developers get a simple, typed API that mirrors Circle’s CCTP SDK. Why this approach: Developers shouldn’t need to understand Move bytecode or blockchain-specific serialization formats. The SDK provides an intuitive interface that reduces onboarding friction for issuers familiar with existing cross-chain protocols.

​

6. Reconciliation & Monitoring (Operational Safety)

The Sui policy contract maintains a canonical ledger of global supply and per-chain balances. A separate reconciliation module periodically queries on-chain balances from each chain, compares against the Sui ledger, emits alerts on drift, and supports automated remediation like pausing the policy or triggering key rotation. Why this approach: Multi-chain systems are complex, and bugs or exploits on one chain can cascade. Real-time reconciliation provides an early warning system, while the Sui ledger serves as the ground truth for audits and forensics.

​

Implementation Priorities

We’re sequencing development to de-risk the hardest problems first: Milestone 1 (Weeks 1-4): Prove the core architecture works

• Deploy Sui contracts (policy registry, burn handler, mint orchestrator)
• Integrate Ika dWallet creation and signature requests
• Implement Solana program (Pinocchio) with full burn/mint flow
• Build minimal issuer agent to coordinate end-to-end flow
• Success criteria: Complete a Solana→Solana transfer on localnet

Milestone 2 (Weeks 5-8): Add EVM support and NFT capabilities

• Deploy EVM contracts (Hardhat) with ECDSA signature verification
• Extend policy registry for NFT metadata and ownership tracking
• Implement NFT burn/mint flows (ERC-721/ERC-1155 on EVM, Sui Kiosk standard)
• Build TypeScript SDK with PDA helpers and transaction builders
• Success criteria: Fungible and NFT transfers between Solana and Ethereum on testnet

Milestone 3 (Weeks 9-12): Production readiness

• Security review (internal audit, threat model, formal verification stretch goal)
• Reconciliation module with drift detection
• Comprehensive documentation (SDK reference, integration guides, reference apps)
• Testnet deployment with demo apps (stablecoin, carbon credit NFT)
• Success criteria: Audit-ready protocol with public testnet demos

This sequencing ensures we validate the riskiest assumptions (Ika integration, cross-chain signature verification, policy enforcement) before investing in polish and documentation.

​

Competitive Positioning

• Wrapped assets (wBTC, wETH): centralized/federated custody → single point of failure.
• Circle CCTP: centralized attestation service → Circle controls cross-chain flow.
• Lock-and-mint bridges: pooled, economic trust in validator set.
• Inkwell CCTP: issuer key share + decentralized MPC + Sui policy contract → non-custodial, deterministic policy enforcement.

​

Alternatives & Differentiation

• Bridges and wrapped assets: introduce custodial or economic trust, standing signing authority, and bridge-specific risk; UX friction and fragmentation remain.
• Circle CCTP: requires centralized attestation service; Circle can censor or delay cross-chain transfers.
• Threshold custody solutions: reduce but do not eliminate trust; complex economic security that can degrade under stress.
• Inkwell CCTP difference: issuer-held imported keys, Sui on-chain policy enforcement, dual-participation signing; no centralized attestation or censorship risk.

​

Team Pitch

​

Team Hiring Timeline

• Seed grant phase: executed by current core contributors; additional hires deferred to investor-funded stage.
• Post-grant: begin full hiring once PoC validated; target 1 month from investor close for all roles.

​

Desirable Features

• CCTP-style cross-chain flows
  • Burn→Mint between supported chains for both fungible and non-fungible assets, no wrapping.
  • Per-chain token/NFT contracts with dWallet minter/burner roles.
• Issuer-centric authority
  • Imported-key dWallet controlling minting authority on all contracts on all chains; issuer retains the full private key.
  • Dual-participation signing: issuer user share + Sui policy approval.
• Policy & risk controls
  • Global/per-chain caps for fungible supplies, issuance quotas for NFTs.
  • Allow/deny lists, jurisdiction gating, pause/resume controls.
  • Versioned, auditable policy changes.
• Operations & reconciliation
  • Canonical supply/ownership ledger on Sui for both fungible and NFT assets.
  • Real-time per-chain reconciliation, drift alerts.
  • dWallet key rotation/reshare without changing authority address.
• Developer ergonomics
  • SDK/REST mirroring CCTP flows for fungible and non-fungible mints/burns.
  • Prebuilt connectors/adapters for major EVM L1/L2s, Sui MoveVM, SVM etc.
  • Reference apps showing end-to-end flows for both token and NFT assets.

​

Deliverables

• Sui Policy Engine contracts for mint/burn approvals (fungible + NFT standards).
• Chain-specific contracts:
  • EVM / Sui / SVM fungible modules (e.g. ERC-20)
  • EVM / Sui / SVM non-fungible modules (e.g. ERC-721 / ERC-1155)
• dWallet authority tooling: imported key creation, binding, rotation, and migration.
• Issuer server/HSM agent:
  • Execution layer: listens for approvals, builds native chain transactions, confirms finality
  • Co-signer for mint/burn execution.
  • Optional: SaaS model where RWA platform and/or other 3rd parties (e.g. qualified custodian) provides secure hosting and HSM integration.
• Reconciliation module: cross-checks on-chain balances/ownership against Sui ledger.
• Issuer console & APIs: unified interface for fungible and NFT issuance.
• Testnet deployment:
  • Fungible RWA demo (e.g., stablecoin)
  • NFT RWA demo (e.g., carbon credit certificate).
  • Security review: covering policy enforcement, dWallet authority, and asset-type-agnostic execution flows.

​

Architecture Overview

​

CCTP Flow (Fungible Assets)

​

CCTP Flow (Non-Fungible Assets)

​

System Architecture

​

Security Posture

​

Trust Model & Authority Flow

• No centralized attestation: Unlike Circle CCTP, there is no centralized service that can censor or delay cross-chain transfers.
• Issuer-held imported keys: The issuer retains the full private key; Ika/Sui cannot censor the issuer.
• Dual-participation signing: Both issuer user share and Sui policy approval are required for any mint/burn.
• On-chain policy enforcement: All policy checks (caps, allow/deny lists, quotas) are deterministic and auditable on Sui.
• Canonical ledger: Sui maintains the source of truth for global supply/ownership across all chains.

​

Threat Model (excerpt)

• Malicious issuer agent: Neutralized by Sui policy contract checks; agent cannot mint beyond caps or violate allow/deny lists.
• Compromised user share: Issuer can rotate/reshare dWallet keys without changing authority address.
• Sui policy contract exploit: Mitigated by formal verification, audits, and governance-controlled upgrades.
• Cross-chain replay attacks: Prevented by nonce tracking and chain-specific transaction hashes.

​

Fee Model

For CCTP, the fee model is issuer-centric:

• Issuer control: Issuers can set 0-1 bps fee (max 0.01%) on burns and mints.
• Protocol share: Inkwell protocol takes 10% of whatever fee the issuer sets.
• Issuer share: Issuer keeps 90% of the fee.
• Example: If issuer sets 1 bps fee, Inkwell gets 0.1 bps and issuer gets 0.9 bps.

​

Fee Flow (simplified)

​

RFP Scope and Timeline

​

Milestone 1: Core Infrastructure (4 weeks)

• Sui Policy Engine contracts
  • Fungible asset policy (caps, allow/deny lists, pause/resume)
  • NFT asset policy (quotas, allow/deny lists, metadata validation)
  • Canonical ledger for supply/ownership tracking
• dWallet integration
  • Imported-key dWallet creation and binding
  • Dual-participation signing (user share + network share)
• Issuer agent (barebones)
  • Listen for burn events on source chains
  • Request mint approval from Sui policy engine
  • Co-sign and submit mint transactions to destination chains

Success Criteria: Happy-path fungible asset burn/mint on testnet (EVM → Sui → EVM)

​

Milestone 2: Multi-Chain Integration (4 weeks)

• Chain-specific contracts
  • EVM fungible (ERC-20) and non-fungible (ERC-721) contracts
  • Sui fungible (Coin) and non-fungible (NFT) contracts
  • Solana fungible (SPL Token) and non-fungible (Metaplex) contracts
• Reconciliation module
  • Cross-check on-chain balances/ownership against Sui ledger
  • Drift detection and alerting
• Issuer console (minimal)
  • View canonical ledger state
  • Configure policy parameters (caps, allow/deny lists, etc.)

Success Criteria: Multi-chain fungible and NFT burn/mint flows on testnet

​

Milestone 3: Security & Polish (4 weeks)

• Security review
  • Internal audit of policy enforcement logic
  • Threat model covering cross-chain attack vectors
  • Formal verification of core safety-critical contracts (stretch)
• Documentation
  • SDK/API reference for issuers
  • Integration guides for EVM, Sui, Solana
  • Reference apps (fungible and NFT demos)
• Testnet deployment
  • Fungible RWA demo (stablecoin)
  • NFT RWA demo (carbon credit certificate)

Success Criteria: Audit-ready protocol with comprehensive documentation and reference apps

​

Budget (Indicative)

• Development: $40,000 (Sui contracts, chain-specific contracts, issuer agent, reconciliation)
• DevOps & Infrastructure: $10,000 (testnet deployment, monitoring, CI/CD)
• Design & UX: $5,000 (issuer console, reference apps)
• Security: $10,000 (internal audit, threat model, formal verification)
• Contingency: $5,000 (cross-chain integration challenges, Ika API changes)
• Total: $70,000

​

Other Funding & Long-Term Vision

​

Current Funding Status

Secured Funding:

• Colosseum Solana Hackathon: Submitted to Arena (pending results)
• Internal Runway: Self-funded development through Q1 2025
• Ika RFP Grant: This proposal for CCTP implementation ($70k)

Pursuing:

• Seed Round: Targeting $500k-$1M from crypto-native VCs and strategic angels (Q1 2025)
  • Focus: Protocol development, team expansion, security audits
  • Target investors: Solana ecosystem funds, DeFi-focused VCs, RWA infrastructure investors
• Sui Foundation Grant: Exploring additional grants for Sui-specific infrastructure and tooling
• Strategic Partnerships: In discussions with RWA issuers and institutional partners for pilot programs

​

Post-RFP Roadmap

Phase 1: Production Readiness (Months 4-6)

• External Security Audit: Engage tier-1 auditors (Trail of Bits, Zellic, OtterSec) for comprehensive review
• Mainnet Deployment: Launch on Sui, Ethereum, and Solana mainnets
• Pilot Programs: Onboard 2-3 RWA issuers (stablecoin, tokenized treasuries, carbon credits)
• Performance Optimization: Gas optimization, latency reduction, UX improvements
• Monitoring & Alerting: Production-grade observability and incident response

Phase 2: Ecosystem Growth (Months 7-12)

• Additional Chain Support: Integrate Bitcoin L2s, Polygon, Arbitrum, Base
• Advanced Features:
  • Programmable policies (time-locks, vesting schedules, compliance rules)
  • Multi-signature governance for policy updates
  • Automated market making for cross-chain liquidity
  • Oracle integration for dynamic supply caps based on collateral
• Developer Tools:
  • SDKs for additional languages (Python, Go, Rust)
  • CLI tools for issuer operations
  • Reference implementations and starter kits
• Community Building:
  • Developer documentation and tutorials
  • Hackathon sponsorships and bounties
  • Integration partnerships with wallets and dApps

Phase 3: Decentralization & Scale (Year 2+)

• Protocol Governance: Transition to community governance with token-based voting
• Decentralized Issuer Agent Network: Enable third-party operators to run issuer agents
• Institutional Partnerships: Onboard traditional finance institutions for RWA tokenization
• Regulatory Compliance: Work with legal partners to ensure compliance across jurisdictions
• Revenue Model: Protocol fees (10% of issuer fees) to sustain development and operations

​

Sustainability Model

Revenue Streams:

1. Protocol Fees: 10% of issuer-set fees (0-1 bps on burns/mints)
   • Conservative estimate: $10M monthly volume × 0.5 bps avg fee × 10% = $500/month initially
   • Growth target: $1B monthly volume × 0.5 bps × 10% = $50k/month by Year 2
2. Enterprise Support: Premium support and custom integrations for institutional issuers
3. Consulting Services: Integration assistance and policy design for complex use cases

Resource Allocation:

• Core Development (40%): Protocol improvements, new features, chain integrations
• Security (20%): Ongoing audits, bug bounties, formal verification
• DevRel & Community (15%): Documentation, developer support, ecosystem growth
• Operations (15%): Infrastructure, monitoring, incident response
• Business Development (10%): Partnerships, issuer onboarding, regulatory compliance

Team Expansion Plan:

• Post-RFP (Months 4-6): Hire 2-3 engineers (protocol, security, DevOps)
• Year 1: Grow to 8-10 team members (add DevRel, BD, community manager)
• Year 2: Scale to 15-20 team members (expand all functions, add legal/compliance)

​

Long-Term Vision

Mission: Become the standard infrastructure for multi-chain RWA issuance, enabling seamless asset flow across all major blockchains without trust assumptions. Success Metrics (3-year horizon):

• Adoption: 50+ RWA issuers using Inkwell CCTP
• Volume: $10B+ in cross-chain transfers annually
• Chains: Support for 10+ blockchain networks
• Decentralization: Fully decentralized governance and operator network
• Impact: Enable $100B+ in RWA tokenization across multiple chains

Competitive Moat:

• First-mover advantage in Ika-based cross-chain RWA infrastructure
• Deep integration with Sui ecosystem and parallel execution benefits
• Non-custodial architecture eliminates regulatory and security risks of competitors
• Open-source contracts and agent build trust and enable ecosystem contributions
• Network effects from issuer adoption and cross-chain liquidity

Exit Strategy (if applicable):

• Protocol remains open-source and community-governed
• Potential acquisition by major blockchain infrastructure provider or RWA platform
• Token launch for governance and protocol sustainability (subject to regulatory clarity)

​

Will your project be open source?

Subject to final alignment with client and partners.

​

FAQ

Show How is this different from Circle CCTP?

Circle CCTP uses a centralized attestation service that can censor or delay cross-chain transfers. Inkwell CCTP uses a Sui on-chain policy engine with deterministic, auditable rules and issuer-held imported keys to eliminate censorship risk.

Show What is the custody model?

Issuers control minting authority via imported-key dWallets. The issuer holds the user share; the Sui policy contract holds the network share. Both must co-sign for any mint/burn, ensuring dual-participation control.

Show How are policy rules enforced?

All policy checks (caps, allow/deny lists, quotas) are executed on-chain in Sui Move contracts. The issuer agent cannot bypass these checks; the Sui policy contract must approve every mint/burn.

Show What chains are supported?

Initially: EVM chains (Ethereum, Polygon, etc.), Sui, and Solana. The architecture is designed to support any chain with smart contract capability.

Show How does reconciliation work?

The Sui policy contract maintains a canonical ledger of global supply/ownership. The reconciliation module periodically cross-checks on-chain balances/ownership against this ledger and alerts on drift.

Show Can issuers rotate keys?

Yes. Issuers can rotate/reshare dWallet keys without changing the authority address on any chain, using Ika’s key rotation/migration features.

Show What happens if the Sui policy contract is compromised?

The issuer can pause minting via their user share, preventing any unauthorized mints. Governance-controlled upgrades and formal verification mitigate this risk.

Show How are fees handled?

Issuers can set 0-1 bps fee on burns/mints. Inkwell protocol takes 10% of the issuer’s fee; issuer keeps 90%. Fees are optional and issuer-controlled.