> ## 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. # What Is Inkwell Finance? > A frontier-cryptography practice. We build financial products and ship services using 2PC-MPC, FHE, and ZK — the primitives most teams cannot integrate on their own. > **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. ## The short version Inkwell Finance is a frontier-cryptography practice. We build financial products and ship services using primitives most teams cannot integrate on their own — **2PC-MPC threshold signing** (via [Ika](https://ika.xyz)), **fully homomorphic encryption** (via [Encrypt](https://encrypt.cc)), and zero-knowledge verification. Two surfaces: * **Products** we operate ourselves — Leviathan, Dagon, Synthase, IKA Staking, LIKA. * **Services & solutions** for teams who need the same primitives in their own stack — Ika dWallet integration, Encrypt-program integration, cross-chain enforcement architectures, confidential compute design. The same engineering bench ships both. ## What "frontier cryptography" means here The cryptographic primitives we work with are real today but not yet commodity. Picking them up requires reading the papers, talking to the core teams, and shipping production code against pre-alpha SDKs. We do that work so the products and clients on top do not have to. Two-party computation MPC, productionised as Ika's dWallet. A signing key is held jointly between a user and a permissioned committee; no single party can sign alone. The committee can enforce policy at the cryptographic level — destination whitelists, daily limits, function-level gates — before agreeing to sign. We use it to make cross-chain enforcement non-custodial. Compute over ciphertexts. Operators see encrypted inputs, run the program, and return encrypted outputs — never observing the plaintext. We use it to build confidential matching venues where even the matching engine cannot front-run the order book. Compact cryptographic proofs that a computation was performed correctly. We use ZK where verification needs to be trustless — typically for cross-chain state attestation — and track the ZK light-client landscape so we can migrate when production-grade primitives ship for the chain pairs we need. Cryptographic structures that decide who can see what, when, and under whose authority — without a single trusted party in the middle. The connective tissue between the three primitives above. ## Products we operate **Revenue-backed credit infrastructure.** Protocols borrow against on-chain revenue; Ika dWallets enforce repayment policy at the cryptographic level. Four Anchor programs on Solana, Sui-based policy gateway, EVM revenue capture. **Confidential matching venue.** FHE-native dark pool on Solana built on Encrypt's REFHE programmable bootstrap. Even the matching operator cannot see flow. **Basis-yield strategy.** Funding-rate arbitrage across 11 perps venues. Validated out-of-sample across bull and bear regimes. **Validator allocation + liquid staking on Sui.** Scoring engine, optimal allocation, Agent API for AI integrations, and LIKA liquid-staked IKA. ## Services we provide We sell the engineering practice behind the products, not the products themselves. Typical engagements: | Engagement | What we deliver | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | **Ika dWallet integration** | Policy design, dWallet provisioning, signing gateway, on-chain capability hierarchy, end-to-end demo on the partner's chain pair | | **Encrypt FHE integration** | Circuit design (op-graph + density planning), executor sizing, on-chain layout, devnet integration against the live `encrypt-program` | | **Cross-chain enforcement design** | Threat model, custody axis analysis, attester / ZK-light-client roadmap, contract-level enforcement primitives | | **Confidential compute architecture** | Selecting between FHE, MPC, TEE, and ZK for a specific compute-and-disclosure problem — and ruling out the wrong choices | | **Cryptographic systems review** | Independent read of an in-flight architecture using primitives we work with daily | We pick engagements where the same primitives drive our products — so the client gets a team that ships this stack in production, not a research lab. Inquiries: [partnerships@inkwell.finance](mailto:partnerships@inkwell.finance). ## Why we sit where we sit We submit to the Ika RFP program with direct code review from the Ika core team. Three submissions to date (P2P Lending, CCTP, Revenue Marketplace). The architecture review loop runs both ways. Dagon was one of the first production op-graphs built against Encrypt's pre-alpha `encrypt-program` on Solana devnet. We track REFHE bootstrap density, op cost, and threshold-decryption roadmap in our own benchmark harness. Solana, Sui, and EVM are not three frontends to the same monolith. Each chain runs the workload it is best at — Solana for throughput, Sui for object-capability policy, EVM for revenue capture. Designing for that heterogeneity is the work. Every product names its load-bearing trust assumptions and the migration path off them. We do not call something "decentralized" when a named attester is in the loop. See [Design Philosophy](/inkwell/design-philosophy). ## Where to go next How we decide what to centralise, what to make trustless, and what to migrate. Who is doing the work. What ships next across products and engagements. What is live today. Threat model, assumptions, and defence-in-depth across the stack. The credit-infrastructure product.