Executive Summary
Traditional finance companies sitting on decades of operational data face a familiar dilemma: the promise of blockchain is real, but the risk of disrupting a working system is equally real. When a major international factoring firm — processing approximately 30,000 invoices per day and generating over 300,000 transaction events daily — approached Lime Institutional to explore whether blockchain could serve as a trusted, scalable "Golden Copy" of their financial state, the answer required more than technical skill. It required a new philosophy.
Lime Institutional designed and delivered a comprehensive Proof of Concept (PoC) — from market analysis to multi-network stress testing — grounded in one core belief: no prudent enterprise should break a working system without first proving its replacement in parallel. The result was a "Shadow System" that processed real system events from the client's existing infrastructure on three blockchain networks (Base, Solana, and Canton), ingesting identical event streams and producing a verifiable on-chain replica of the client's collateral state.
The PoC successfully stress-tested all three networks at up to 11,000 operations per day — well beyond the client's current production load. Canton emerged as a standout for enterprise deployment, combining privacy-by-design with legal enforceability in ways that public chains cannot natively match. The engagement has since advanced to Phase 2: an MVP build on Solana and Canton.
300K+
Daily operations stress-tested
3
Blockchain networks benchmarked
AR
Primary workflow modelled on-chain
Phase 2
Current status MVP in progress
1. The Problem
A High-Volume Business at a Strategic Inflection Point
The client is an international freight factoring company — a category of financial services where businesses sell their unpaid invoices (accounts receivable) to a factor in exchange for immediate liquidity. The operational scale is significant: roughly 30,000 invoices processed daily, each triggering a cascade of downstream events — purchase confirmations, fee accruals, payments, reserve calculations, and status transitions — that together amount to more than 300,000 discrete transaction events every day.
This volume is managed today by a sophisticated off-chain system. It works. But as the company's leadership looked ahead to investor transparency, operational resilience, and the emerging infrastructure of tokenised real-world assets (RWA), three questions crystallised:
- Could a blockchain network actually handle this transaction load without degradation?
- Could on-chain state be trusted as a verifiable "Golden Copy" of the financial truth — one that investors and auditors could read directly?
- Could the complexity of freight factoring mechanics — collateral aggregation, reserve holdbacks, ineligibility logic, SPV bond facilities — be faithfully represented on-chain?
Why Standard Blockchain Pilots Fail This Problem
Most enterprise blockchain pilots fail not because the technology is insufficient, but because they attempt too much, too fast. They try to replace existing systems rather than prove a concept alongside them. The result is disruption without validation — a recipe for project abandonment.
A second failure mode is architectural: many projects in the RWA and receivables tokenisation space (Huma Finance, Centrifuge, Polytrade, and others) make a pragmatic choice to store only cryptographic hashes of asset data on-chain — keeping actual invoice details off-chain for privacy and cost reasons. This is defensible at scale, but it trades transparency for efficiency.
For an enterprise seeking to prove that the blockchain can genuinely serve as a trusted source of truth, a hash-only approach answers the wrong question.
KEY TENSION: The client's blockchain architect took a principled position: full asset metadata on-chain, not just fingerprints. Lime Institutional engaged this seriously — it is the kind of position that tests the real capabilities and limits of each network.
2. Market Analysis: What the Landscape Revealed
Before a single line of code was written, Lime Institutional conducted a structured analysis of the existing RWA receivables tokenisation landscape. The goal was not to catalogue competitors, but to extract design decisions — specifically, which architectural choices have been proven, which trade-offs are most consequential, and where the gaps are for an enterprise factoring use case.
The Transparency Spectrum
The market has settled into three broad architectural patterns for representing receivables on-chain:
| Architecture | Approach | Representative Projects | Investor Visibility |
|---|---|---|---|
| A — Individual Asset NFT | Each invoice minted as a unique on-chain token with full metadata | Centrifuge, Polytrade, Bulla Network | Maximum — per-asset status, maturity, overdue flags |
| B — Opaque Receivable ID | Receivable exists on-chain but content is privacy-preserving (hash only) | Huma / Arf | Aggregate pool performance only |
| C — Pool Token Only | No individual asset representation; only pool TVL and yield on-chain | ABHI / ZIGChain, Tala via Huma | Minimal — deposit/withdrawal flows only |
The critical insight from this analysis: Architecture B and C — while operationally pragmatic — create an inherent trust gap. Huma Finance, the largest player in the PayFi space with over $10 billion in cumulative volume, has publicly acknowledged that its yield is "probably real, but not verifiably real."
Fraud or mismanagement would be undetectable in real time by liquidity providers. This is a structural weakness that no amount of tokenisation solves if the underlying data is opaque.
DESIGN INSIGHT: For an enterprise seeking investor transparency as a core use case — not a secondary benefit — Architecture A (full individual asset representation) is the only approach that genuinely closes the trust gap. This shaped every subsequent design decision.
The Capital Deployment Models
The team also mapped the dominant capital deployment models in the market, ranging from per-invoice marketplaces (maximum transparency, limited scalability) to revolving credit lines against receivable portfolios (highest capital efficiency, concentrated trust). For a freight factoring operation processing 30,000 invoices daily, the revolving credit line model — where collateral pools back a dynamic credit facility — most closely mirrors existing operations and offers the clearest on-chain migration path.
Canton: The Enterprise Outlier
The most consequential finding from the market analysis was not about a competitor — it was about a network. Canton, developed by Digital Asset, is not a classical public blockchain. It is a privacy-first, legally-integrated distributed ledger designed specifically for financial institutions. While Solana and Base compete on throughput and developer ecosystem, Canton competes on an entirely different dimension: the ability to handle the privacy requirements and legal enforceability demands of regulated finance without compromise.
By prioritizing granular data confidentiality and rigorous regulatory alignment, Canton represents a high-potential 'white space' that directly addresses the client's most critical requirements, making it a vital third network for our benchmark.
3. The Solution: Architecture and Design Decisions
The Shadow System Philosophy
The foundational design decision of the entire engagement was the Shadow System model. Rather than attempting to migrate or replace the client's existing infrastructure, Lime Institutional designed a parallel on-chain recorder that ingests the identical stream of events as the off-chain system — in real time.
This is not a compromise. It is the correct approach for enterprises at this stage of blockchain adoption.
STRATEGIC PERSPECTIVE: We are at a junction point of crossing the DeFi chasm — where the early majority of enterprise adopters are more risk-sensitive than opportunity-sensitive. Controlled, auditable pilots that prove a concept works in practice, without disrupting live operations, are not a stepping stone to blockchain adoption. They are the definition of responsible blockchain adoption.
The Shadow System operates as follows: a microservices layer ingests real events from the off-chain system, performs calculations, and updates the blockchain state. These state updates simultaneously trigger on-chain calculations within the smart contracts, which function as a State Verification Ledger. The goal is a single, verifiable equation:
Off-chain State ≡ On-chain State
When that equation holds — verifiably, at 11,000 operations per day — the blockchain has earned the right to be called a Golden Copy.
The Full Data On-Chain Decision
The client's architect took a position that runs deliberately counter to most of the market: all asset metadata should be stored directly on-chain, not just cryptographic hashes. This is a principled stance, and Lime Institutional engaged it seriously through extended internal discussion.
The arguments for hash-only storage are well-established: lower storage costs, simpler GDPR compliance, protection of commercially sensitive invoice data. Virtually every major project in the space — Figure Markets with its Encrypted Object Store, Huma with its opaque receivable IDs, Centrifuge with off-chain EOS — takes this approach.
But the client's reasoning was strategically coherent: this is a PoC. The purpose is precisely to stress-test what the networks can do. A hash-only approach would answer a narrower question. Full data on-chain answers the harder one — and forces each network to reveal its real cost structure, privacy model, and throughput characteristics under genuine load.
ARCHITECTURAL OUTCOME: The decision to store full asset metadata on-chain became one of the most revealing aspects of the network comparison. It exposed Canton's privacy-by-design advantage with particular clarity: unlike Solana (public by default) or Base (EVM public chain), Canton's sub-transaction privacy model ensures that full data is visible only to the parties involved in each contract.
Collateral Logic: The Core Factoring Mechanics On-Chain
Beyond the token architecture, the team designed the on-chain representation of freight factoring's core financial mechanics — a domain where imprecise modelling would undermine the entire Golden Copy claim.
The key constructs included:
- Relationship Pools: Each unique Supplier ↔ Debtor pair is a distinct contractual bucket. Collateral aggregates are tracked live at the pool level — total collateral, funds employed, and reserve balance.
- Asset State Machine: Each invoice moves through a defined lifecycle — FUNDED → INELIGIBLE / SHORT_PAID / COMPLETED — with each transition triggering automatic aggregate updates.
- Multi-Level FIFO Allocation: When Funds Employed is less than total collateral, the system allocates financing to invoices sorted by due date (primary) then issue date (secondary), with support for partial allocation of a single invoice.
4. Network Benchmarking: Base, Solana, and Canton
Testing the same tokenisation architecture and event load across three fundamentally different blockchain networks was one of the most analytically valuable aspects of the engagement. Each network has a distinct design philosophy — and those philosophies manifest as real trade-offs when confronted with the demands of enterprise financial infrastructure.
| Dimension | Base (EVM) | Solana | Canton |
|---|---|---|---|
| Architecture | EVM-compatible L2 on Ethereum | High-throughput SVM | Privacy-first DAML-based DLT |
| Throughput | High — L2 economics favour volume | Very high — designed for scale | High — with privacy overhead |
| Privacy model | Public by default | Public by default; Token-2022 extensions add compliance layer | Sub-transaction privacy inherent in contract model |
| Compliance enforcement | At contract level; requires custom logic | Token-2022: TransferHook, DefaultAccountState, PermanentDelegate | Encoded in DAML template pre-conditions; custodian co-signature required |
| Full data on-chain | Feasible; visibility is fully public | Feasible; visible to all chain readers | Feasible; visible only to contract parties |
| Legal integration | Relies on external legal wrappers | Relies on external legal wrappers | Identity at party level; bilateral contracts with legal standing |
| Enterprise fit | Strong developer ecosystem; battle-tested | Growing institutional adoption; Circle / Huma precedents | Highest natural fit for regulated finance; emerging ecosystem |
Canton: The Standout Finding
Canton was the network that most surprised the team — and the one that most clearly addresses the specific needs of an enterprise factoring migration.
In most blockchain contexts, privacy is bolted on: an afterthought implemented through token extensions, zero-knowledge proofs, or off-chain data storage. In Canton, privacy is inherent in the contract model. Every holding is a bilateral contract requiring co-signatures from both custodian and owner. Compliance rules are encoded directly in DAML template preconditions — the ledger itself rejects non-compliant transactions before they ever reach consensus. Regulators can be added as observers without exposing data to other participants.
For a company processing sensitive commercial invoices — where a supplier's financing relationship with a specific debtor is competitively sensitive information — this is not a minor feature. It is the difference between a network that can theoretically handle the use case and one that was architecturally designed for it.
CANTON INSIGHT: Although Canton is not a classical blockchain in the public-chain sense, it is emerging as a network capable of simultaneously handling the privacy requirements and legal enforceability demands of 24/7 open finance. This is a major and underappreciated USP for enterprise deployments.
Testing on Real System Data
The system was tested against real operational data from the client's existing infrastructure, processing up to 11,000 operations per day across all three networks. Rather than synthetic load generation, this approach validated the architecture against genuine business events — purchase confirmations, fee accruals, payment collections, and status transitions — providing a meaningful proof of correctness under real-world conditions.
All three networks processed the event load correctly. The differentiation emerged not in raw throughput, but in the qualitative characteristics that matter most to an enterprise deployer: privacy model, compliance architecture, and how each network handles the overhead of full asset data on-chain.
5. Results and Impact
The PoC delivered against all three of its original business objectives — and surfaced insights that have directly shaped the client's Phase 2 strategy.
Objective 1: Performance Benchmarking
All three networks — Base, Solana, and Canton — demonstrated the ability to sustain 500,000 operations per day via the Event Harness. This definitively answers the scalability question that motivated the engagement: blockchain infrastructure, when properly architected, can handle the throughput demands of a high-volume factoring operation. The question for Phase 2 is not whether the networks can scale, but which network's specific characteristics best match the client's production requirements.
Objective 2: Shadow Verification
The Shadow System achieved its core goal: on-chain state parity with the off-chain system across all tested event types. The Collateral Balance — anchored in the Accounts Receivable (AR) workflow — was accurately maintained on-chain through the invoice lifecycle: creation, aging, partial payment, disputes, dilution events, and full settlement. The system correctly tracked ineligibility transitions and asset state changes as real events were processed.
Objective 3: Investor Transparency
The PoC demonstrated that smart contracts can provide investors with a real-time, independently verifiable view of the assets backing bond facilities — without requiring access to the client's internal systems. Reserve levels, liquidation statuses, and bond health ratios are all queryable directly from the chain. This transforms investor due diligence from a periodic reporting exercise into a continuous, auditable data feed.
The Outcome: Phase 2
On the strength of the PoC results, the client has committed to Phase 2: an MVP build targeting both Solana and Canton as production networks. The dual-network approach reflects the complementary strengths identified during benchmarking — Solana's throughput and ecosystem depth alongside Canton's privacy model and enterprise legal integration.
WHAT THIS SIGNALS: The decision to proceed with two networks rather than one is itself a statement of strategic maturity. The client is not converging on a single blockchain religion. They are building optionality into their infrastructure — which is exactly what a risk-sensitive early majority enterprise should do at this stage of the market.
6. Lessons for Enterprise Blockchain Adoption
This engagement crystallised a set of principles that Lime Institutional believes apply broadly to any traditional finance company exploring blockchain migration. They are not theoretical — they emerged from the specific challenges of designing, building, and stress-testing a production-grade PoC in a complex domain.
Lesson 1: The Shadow System is the Right Starting Point
Do not replace a working system. Run alongside it. The Shadow System model provides the empirical evidence — not vendor claims, not white papers — that the blockchain can match your operational reality. It de-risks the migration path and creates a clear, auditable benchmark for go / no-go decisions.
Lesson 2: The Token Architecture is the Product
The most common mistake in enterprise blockchain projects is treating tokenisation as a technical detail — a mapping exercise from database records to on-chain structures. It is not. The token architecture is where business logic lives on-chain. Getting it wrong means rebuilding from scratch. For this engagement, the tokenisation design — covering identity, value, financing, relationships, and borrowing capacity — required significant effort precisely because it had to faithfully model a domain with decades of accumulated complexity. That design work is ongoing into Phase 2.
Lesson 3: Test the Purist Case First
The instinct to compromise early — storing hashes instead of data, simplifying compliance logic, deferring the hard cases — produces a PoC that proves a smaller claim than you need. Store the real data. Model the negative balances. Implement the ineligibility transitions. The full-fidelity case is harder to build, but the results are unambiguous. If the system handles the full complexity of your domain, you know what you have.
Lesson 4: Network Choice is a Multi-Dimensional Decision
Throughput is table stakes. The differentiation between networks for enterprise use cases lies in privacy model, compliance architecture, legal integration, and ecosystem maturity. Solana and Base answer the scalability question conclusively. Canton answers a different — and for regulated finance, arguably more important — set of questions about data confidentiality and legal enforceability. Test all three before committing.
Lesson 5: The Early Majority Needs a Different Conversation
The DeFi narrative — permissionless, open, disruptive — is the wrong frame for enterprise finance. The early majority of institutional adopters are not ideologically opposed to blockchain; they are operationally cautious. The conversation that works is not "blockchain will replace your infrastructure." It is: "Here is a controlled, auditable pilot that proves, in parallel with your live system, that this technology can match your operational reality. The decision to migrate is yours, backed by data."