> ## 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. # Design Philosophy > We aim to be as decentralized as possible given what the ecosystem can trustlessly support. Where we fall short, we name it and commit to migrate. > **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 principle Every system Inkwell ships faces the same tradeoff: how much decentralization do we surrender for how much user experience, latency, or feature completeness? Our default: **as decentralized as possible today, given what the ecosystem can trustlessly support**. Where current ecosystem primitives don't exist for a fully trustless implementation, we document what we do instead, why, and under what conditions we migrate off the centralized path. This is not *"decentralized eventually."* It is *"decentralized where feasible today, centralized where honest — and documented in both directions."* ## What decentralization means here Decentralization is not a single bit. Every system lives on five independent axes. A system can be fully decentralized on one axis and centralized on another, and the honest frame is to name all five: Are user funds held by the protocol, or by the user? **Inkwell's position**: non-custodial wherever physics permits. Users hold their own keys; the protocol never holds a honeypot. This is the one axis where we do not compromise. Does the protocol finalize state, or does a public chain's consensus finalize state? **Inkwell's position**: on-chain settlement on the chain best suited to each product. Solana for Leviathan and Dagon because the throughput/fee profile matches their execution patterns; Sui for IKA Staking because that is where the IKA token lives. Does a single operator or a cryptographic rule decide what can happen? **Inkwell's position**: cryptographic rules wherever the execution model allows. Where an operator is required (e.g. running an FHE matching engine), the operator is cryptographically blind — structurally unable to see or front-run the data it processes. Who attests that off-chain or other-chain state is correct, and can that attestation be trusted without a human in the loop? **Inkwell's position**: trust-minimized verification wherever a production-grade primitive exists. Where it doesn't — specifically for cross-chain state verification — we use named attesters today and commit to migration when ZK light clients ship. See the [leviathan-verifier case study](#case-study-leviathan-verifier) below. Who decides what the protocol does next — token holders, a company, a foundation? **Inkwell's position**: the company decides today. Governance tokens, in our view, are mostly Howey problems waiting to happen. When a credible on-chain governance primitive exists that doesn't require securities sleight-of-hand, we'll consider it. ## Case study: `leviathan-verifier` Leviathan is a credit protocol designed to work across Solana, EVM, and (on the roadmap) Sui. When a loan's collateral sits on one chain and its revenue stream lands on another, the home-chain smart contract needs to **verify the other chain's state** before updating loan health. ### The trustless version we cannot ship today The ideal design is a ZK light client: a verifier program on chain A that validates a compact ZK proof attesting to the state of chain B. Chain A's consensus becomes sufficient to trust chain B's state — no operator, no attester, no committee. That primitive does not exist in production for the chain pairs Leviathan operates on. The candidates we track: * **Succinct SP1** — general-purpose ZK VM, Ethereum-centric, maturing. * **Polygon AggLayer** — cross-chain ZK settlement fabric, EVM-focused. * **RISC Zero Bonsai** — proof marketplace, high cost per proof today. * **Helios / Lodestar** — Ethereum light clients; in Solana-program form they blow the compute budget. * **Wormhole Queries / Axelar / Chainlink CCIP** — oracle models, not trustless (committee-based). None of these lets a Solana program, inside the current compute budget, verify Ethereum block headers + Merkle-Patricia proofs permissionlessly. That is the gap. ### What we ship instead `leviathan-verifier` is **centralized on the verification axis today**. * The Leviathan operator runs an attester service that watches the counter-chain. * The attester signs `(event, proof, block_hash)` tuples. * The home-chain program verifies the attester's signature, not the underlying chain-level cryptographic proof. This is a one-of-one trust assumption. If the attester is compromised or censors, loan state updates stop — but funds cannot be stolen, only stalled (custody remains decentralized). The failure mode is availability, not integrity. ### The migration path The centralization is explicit, tracked, and time-boxed: * `leviathan-verifier` has a published interface identical on both sides of the migration — the switch from named-attester to ZK-light-client is a back-end swap, not a protocol rewrite. * When any of the primitives above ships production-grade verification for the chain pair we need, we migrate. * Until then, the attester's signing keys are held under multi-party signature, and every signed attestation is archived publicly for third-party audit. ### The honest positioning Leviathan is: * Non-custodial ✅ * Settled on Solana consensus ✅ * Authorized by on-chain logic ✅ * **Verified by a named attester, until ZK light clients ship** ⚠️ * Governance-centralized (company-run) ⚠️ We don't call this "decentralized." We call it "non-custodial revenue-backed credit with a tracked trust assumption on the verification axis." That framing lets counterparties understand exactly what they are taking on. ## Other tracked centralization points For completeness, here are the load-bearing trust assumptions in other Inkwell products: * **Dagon** — operator-mediated matching today (cryptographically blind, but liveness depends on the operator cranking batches). Target end-state is a decentralized threshold-FHE committee — a quorum of independent parties each holding key shares, no single party able to decrypt — gated on Encrypt REFHE shipping production threshold decryption. See [Dagon: Decentralized?](/dagon/faq/decentralized-or-not). * **IKA Staking agent API** — the recommendation engine is a hosted service; the underlying stake transactions are non-custodial and signed by the user's wallet. The agent cannot move stake without user authorization. * **Leviathan credit scoring** — revenue attribution uses off-chain indexers. Scores are computed transparently and published, but the indexing pipeline is operator-run until a decentralized revenue-attribution primitive exists. ## Why we publish this A project that claims to be "fully decentralized" while running a named attester is either confused about what the words mean or dishonest about what it ships. Either way, counterparties can't price the trust assumptions they're taking on. Our bet is the opposite: explicit tracking of every trust assumption, explicit migration paths, and public logs where the centralization currently lives. Counterparties who need to model their exposure can do it. Regulators who need to understand the architecture can do it. And when the ecosystem ships better primitives, the swap is a back-end change, not a crisis of positioning.