Lendscape — Lending Against Tokenized Assets

Deal context

Lendscape is a white-label lending platform developed by Asset Haus to enable loans against tokenized assets. The engagement, dated Q2 2025, was not a single-asset tokenization — it was a platform build: private-credit infrastructure designed for repeat deployment under an operator's own brand. The stack runs on Ethereum, addresses a global lender base across multiple jurisdictions, and combines four capabilities that rarely ship together: automated collateral scoring, junior-senior tranche pools, custom loan-to-value (LTV) logic per collateral type, and automated liquidation. Alpha-phase volume reached approximately $5 million, with production launch targeted for Q1–Q2 2026.

The structuring problem

A lending platform is a fundamentally different structuring object from a single deal. A one-off tokenization answers one question — how does this asset reach these investors — and can afford bespoke answers. A platform has to answer at the category level, three times over:

• Multi-deal registry. The system must carry many concurrent loans against heterogeneous tokenized collateral, each with its own scoring result, LTV parameters, and liquidation thresholds, without the bookkeeping degrading as the loan count grows.
• Operator branding. As a white-label product, the operator's brand and front end face lenders and borrowers; the underlying infrastructure stays invisible. The structure has to survive that separation cleanly.
• Repeatable onboarding. New collateral types, new lenders, and entirely new deployments must be configuration exercises, not re-engineering projects.

On top of this, risk segmentation had to be productized. Junior-senior tranching is usually negotiated per deal; here it becomes a standing feature — a junior pool that takes first loss for higher yield and a senior pool that sits protected at lower yield — available to every loan the platform originates.

Jurisdiction and compliance constraints

The platform is multi-jurisdiction by design, so the build treats compliance as a per-deployment configuration rather than a fixed perimeter. Each operator taking the white-label stack defines its own compliance rules — who may lend, which collateral is eligible, what controls apply — working with qualified counsel in the jurisdictions where it operates. Asset Haus provides the infrastructure and structuring support; the operator holds whatever licenses or permissions its lending activity requires. Automated liquidation rules form part of that compliance envelope: encoding the triggers and execution logic means lender-protection mechanics behave consistently instead of depending on manual intervention. This is the pattern-level framing — specific regulatory treatment varies by deployment and must be confirmed with counsel.

Platform modules deployed

This case is fundamentally about the module stack. Five modules were deployed, each mapping to a deliverable an operator can take into production.

Lending Engine. The origination and servicing core: it books loans against tokenized collateral, tracks repayment, and routes distributions to the pools as loans repay. The platform architecture deliverable documents how this engine, the pools, and the risk modules interlock — the blueprint an operator's team runs against.

Scoring System. Automated assessment of tokenized collateral, delivered with the underlying scoring methodology. Rather than a credit officer reviewing each pledge, the system evaluates collateral programmatically and feeds the result into LTV assignment. Because collateral is heterogeneous, LTV logic is custom per collateral type — each asset class gets its own ratio logic instead of one flat haircut across the book.

Junior-Senior Pool Management. The tranche machinery as a standing structure. The junior pool absorbs first loss in exchange for higher yield; the senior pool is protected and yields less. Every loan on the platform inherits this segmentation, so lenders self-select a risk position once rather than renegotiating it deal by deal.

Liquidation Module. Automated triggers and execution, backed by a liquidation mechanism design deliverable. When a position breaches its parameters, the module acts on encoded rules — the piece that makes the LTV logic enforceable rather than advisory.

White-Label Configuration. The layer that turns the above into a repeatable product: operator branding, per-deployment compliance settings, and a white-label deployment kit that packages the stack for the next operator launch.

Investor and deal workflow

The documented architecture supports a two-sided flow. Lenders — the platform's users, with variable ticket sizes — onboard and allocate to the junior or senior pool according to risk appetite. On the borrowing side, tokenized assets are pledged as collateral, the scoring system evaluates them, and the collateral-type LTV logic sets borrowing capacity before the lending engine originates the loan. Distributions to lenders occur on loan repayments.

Repeat issuance is the point of the design: each new loan travels the same rails, and each new collateral type is an onboarding exercise — scoring parameters, LTV logic, liquidation thresholds — rather than a rebuild. At the operator level, the deployment kit repeats the pattern again: a new branded platform instance instead of a new engineering project.

Registry, settlement, and reporting logic

Positions live on Ethereum, with the pool structure providing the segregation logic: junior and senior balances are accounted separately, and each loan carries its own collateral record and parameter set, so one loan's performance is legible independently of the book around it. Settlement follows the encoded rules — repayments flow through the lending engine to the pools, and under-collateralized positions are handled by the liquidation module's automated triggers and execution. Because scoring, LTV, and liquidation parameters are explicit per loan, the same records that drive settlement give the operator a book-level view across every deployment it runs.

Outcome and current status

Per the documented results: the build is completed, the platform is white-label ready, alpha volume reached approximately $5 million, and launch is targeted for Q1–Q2 2026. The usual hedges apply — alpha volume reflects a testing phase rather than sustained production demand, launch timing is a plan rather than a guarantee, and nothing here implies guaranteed liquidity or lender returns. See the broader case library for how this build compares to single-deal engagements.

What operators can reuse

• Structure the platform, not the first deal. Registry, pools, and onboarding must be designed for loan N, not loan one — retrofitting multi-deal logic onto a single-deal build is the expensive path.
• Productize risk segmentation. A standing junior-senior structure lets lenders pick a risk position once, instead of re-cutting tranches per transaction.
• Treat compliance as configuration. Multi-jurisdiction platforms need per-deployment compliance settings defined with counsel; the operator holds the licenses, the infrastructure enforces the rules.
• Automate the downside first. Scoring, per-collateral LTV, and automated liquidation are the credibility core of a lending platform — build these before the front end.
• Ship a deployment kit. If launching the next branded instance is a packaged exercise, the platform is a product; if it requires engineers, it is still a project.

Related resources

• White-label tokenization platforms
• How to tokenize a loan portfolio
• On-premise deployment
• Solutions for platform builders
• Deployment models