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

Revenue enforcement is the mechanism that makes Leviathan loans self-repaying. Rather than relying on borrowers to manually transfer repayments, the protocol captures revenue at the source through smart contracts deployed alongside the borrower’s revenue-generating operations. This is the core innovation that distinguishes revenue-backed lending from traditional unsecured debt: repayment is enforced by code, not by collection efforts.

​
How It Works

​
Revenue Flow

  1. A borrower’s protocol generates revenue on an EVM-compatible chain
  2. Revenue flows into a RevenueSplitter contract instead of directly to the borrower
  3. The splitter automatically divides incoming funds according to a pre-configured ratio
  4. The borrower’s share goes to their operational wallet
  5. The repayment share goes to the lender’s designated address
  6. A revenue oracle reports the repayment event back to the Solana loan account
The borrower never touches the repayment portion — it is separated at the contract level before reaching the borrower’s wallet.

​
RevenueSplitter Contracts

RevenueSplitter is a set of EVM smart contracts deployed on chains where borrowers generate revenue:

​
Core Contract

Each RevenueSplitter instance is configured with:
  • Split ratio — the percentage of revenue directed to loan repayment vs. borrower operations
  • Recipient addresses — the lender’s repayment address and the borrower’s operational address
  • Token whitelist — which tokens the splitter accepts and processes
Once deployed, these parameters are immutable for the duration of the loan. The borrower cannot modify the split ratio or redirect the repayment portion.

​
Factory Pattern

The RevenueSplitterFactory contract handles deployment of per-loan splitter instances:
  • Each loan gets its own dedicated RevenueSplitter
  • The factory ensures consistent deployment with validated parameters
  • Splitter addresses are deterministic — they can be computed in advance and verified by all parties
The factory pattern ensures that every splitter is deployed with the correct parameters and that no manual configuration step can introduce errors or manipulation.

​
Revenue Oracle Attestations

On-chain revenue capture on EVM chains needs to be reflected on Solana, where the loan account tracks repayment progress. Revenue oracles bridge this gap:

​
How Attestations Work

  1. Oracle operators monitor RevenueSplitter contract events on EVM chains
  2. When a revenue split occurs, the oracle records the amount, timestamp, and transaction hash
  3. The oracle submits an attestation to the Solana loan account with cryptographic proof
  4. The leviathan-core program validates the attestation and updates the loan’s repayment balance

​
Off-Chain Revenue

Not all borrower revenue flows through on-chain contracts. For off-chain revenue sources:
  • Borrowers submit revenue attestations through a governed process
  • Oracle operators may independently verify off-chain revenue claims
  • Attestations are recorded on-chain with their verification status
Off-chain revenue attestation provides coverage for revenue streams that cannot be captured directly by smart contracts, while maintaining transparency about the verification level of each data point.

​
Why Contract-Level Enforcement?

Traditional lending relies on the borrower’s willingness and ability to make payments. Revenue-backed lending with contract-level enforcement changes the dynamics:
Traditional LendingRevenue-Backed Enforcement
Borrower transfers payments manuallyRevenue is split automatically at the source
Default requires legal collectionDefault is detected programmatically
Revenue diversion is hard to detectRevenue must flow through the splitter to reach the borrower
Enforcement depends on jurisdictionEnforcement is chain-native and jurisdiction-independent
Contract-level enforcement reduces — but does not eliminate — default risk. A borrower could generate revenue through channels that bypass the splitter, or their revenue could decline below expected levels. The protocol’s health monitoring and policy enforcement mechanisms provide additional layers of protection.

​
Integration with Loan Lifecycle

Revenue enforcement integrates with the broader loan lifecycle:
  • At funding — RevenueSplitter is deployed and the borrower’s revenue channels are configured to flow through it
  • During active phase — revenue oracles continuously report repayment progress; health checks verify that actual revenue meets projections
  • At completion — once the repayment cap is reached, the splitter can be deactivated and revenue flows directly to the borrower
  • On default — if revenue falls short, the protocol can escalate to enforcement actions through the policy-gated dWallet