NPLEX Light Paper

1. Abstract

NPLEX is a blockchain-based platform for tokenizing Non-Performing Loan (NPL) packages using the IOTA network. The platform enables verified investors (both institutional and retail, unified under a single ROLE_INVESTOR credential) to participate in NPL investments through fractional ownership via the proprietary LTC1 (Loan Token Contract) standard.

The core philosophy of the protocol is to align incentives between Investors (Capital) and Servicers (Labor) through "Skin in the Game". The protocol caps primary token sales at 95% of total supply (MAX_INVESTOR_BPS = 950,000), leaving at minimum 5% of supply within the originator's economic sphere. Note: secondary market fractionalization of already-tokenized investor positions is architecturally possible via FractionalVault.

2. Protocol Architecture

The NPLEX smart contract ecosystem operates on a modular, three-layer architecture designed for compliance, extensibility, and security.

• Layer 1 (Registry): The core validation and identity gatekeeper. Manages DIDs, roles, and approved notarizations.
• Layer 2 (LTC1): The primary tokenization module. Enforces the 2‑Asset Model for NPL ownership and investment.
• Layer 3 (Fractional): An optional liquidity layer. Vaults that split LTC1 positions into standard fungible coins for DEX trading.

3. NPLEX Registry

The NPLEXRegistry is a shared object acting as the system's ultimate source of truth. It manages the approval flow for off-chain legal documents and on-chain identities. Administrative authority is granted via the NPLEXAdminCap (which uniquely possesses `key` and `store` abilities).

• Notarization Flow: Legal NPL documents are hashed and stored in immutable IOTA Notarization objects (created via IOTA SDK). Administrators register the raw notarization ID and document hash in the Registry — the actual Notarization object is NOT passed to register_notarization. A physical &Notarization<u256> reference is required only for subsequent admin mutations (revoke, approve_identity, update authorized creator, etc.) as a cryptographic audit trail. Each registered notarization is tightly bound to a specific authorized_creator address, which the Admin can update via update_authorized_creator. At contract creation, an executor consumes a Hot Potato NotarizationClaim ticket, ensuring a single notarization is inextricably bound to only one tokenized contract.
• Ticket System: Sensitive cross-contract operations (like ownership transfers or stopping sales) require the Registry to issue an authorization ticket, which the target module must consume in the same transaction.
• Witness Pattern: The ticket system is secured via the One-Time Witness pattern (e.g., LTC1Witness has drop). This enforces that only the explicitly authorized executor module can consume registry tickets and bind notarizations.

4. The 2-Asset Model (LTC1 Standard)

Unlike generic token standards, the LTC1 protocol uses a strict 2‑Asset framework per NPL pool, bound together by Decentralized Identity (DID):

• LTC1Package (The State): A Shared Object instantiated by a verified Institution (ROLE_INSTITUTION) representing the asset. It holds the funding pool, revenue pool, critical configuration details (like token_price, nominal_value, and metadata_uri), and crucial business logic. It stores an owner_identity: ID field pointing to the physical owner, a notary_object_id: ID providing external cryptographical linkage, while precisely tracking tokens_sold against the max_sellable_supply. Each package enforces a minimum total supply of 1,000,000,000 units (MIN_SUPPLY) to mitigate division-rounding dust. Note: while the package conceptually represents an NPL pool, the Move package is structurally domain-agnostic — NPL semantics are upheld at the application layer. Similarly, configuration fields like total supply and nominal value do not currently expose a public mutator, though future iterations plan strict transfer::freeze_object enforcement.
• LTC1Token (The Investment): Owned NFTs distributed to investors. They have the `key` ability (no `store`), preventing unauthorized wrapping, and explicitly enumerate `id: UID`, `balance: u64`, `package_id: ID`, and `claimed_revenue: u64`. Purchasing LTC1 tokens (enforcing amount > 0) requires a valid ROLE_INVESTOR DID. Instead of transferring a token blindly, peer-to-peer ownership moves via a secure, DID-gated transfer_token method (which emits a specific TokenTransferred event). An additional package-internal send_token_to helper exists (no DID gate) exclusively for sibling module operations such as fraction redemption.

5. Revenue Distribution Mechanism

NPLEX uses a deterministic, proportional (Pari-Passu) model to distribute recovered debts. Every token holder with a valid ROLE_INVESTOR DID receives a share strictly equal to their percentage of the total supply. Complex tranche waterfalls are deliberately avoided to protect retail investors.

Cross-Package Protection: Each claim operation cryptographically verifies that the presented token belongs to the target package (token.package_id == package.id), preventing cross-package revenue attacks. If the internal calculation determines due == 0, the claim safely acts as a no-op returning early.

Dividend-Stripping Protection: When new tokens are purchased during an active sale, the contract pre-sets theirclaimed_revenue equal to the historical revenue per share up to that moment. This prevents new buyers from instantly "leeching" previously deposited yields. The equivalent value is allocated to the Originator's owner_legacy_revenue.

Owner Revenue Share: The originator is entitled to revenue proportional to the currently unsold token supply, plus accumulated legacy revenue from previously sold tokens (the dividend-stripping back-pay). Owner claims are doubly-gated: the caller must hold a valid ROLE_INSTITUTION DID whose Identity matches the package's owner_identity field.

6. Fractionalization

To provide secondary market liquidity without compromising the strict compliance tracking of LTC1Tokens, NPLEX provides a native Fractionalization module.

Investors can lock a portion of their LTC1Token position into a FractionalVault (a struct possessing `key` but no `store` abilities). The protocol enforces that the original token must retain at least 1 unit of balance — full-position fractionalization is not permitted, preserving the token stub as proof of the original investment. The vault locks a TreasuryCap and mints standard Coin<F> tokens proportional to the locked balance. These highly fungible fractions can be traded on any standard IOTA DEX. Any holder of Coin<F> — including secondary DEX buyers — can burn fractions to redeem a new LTC1Token (permissionless, no DID required), or merge fractions back into an existing token (which explicitly validates vault.package_id == ltc1.package_id(token)), automatically inheriting the correct proportion of historical claim data, ensuring revenue flow remains perfectly synchronized. Empty vaults can then be manually destroyed to clean up network state.

7. DID-Gated Access & VC Integration

In compliance with institutional banking standards, every participant—from the Admin to the smallest retail investor—must authenticate on-chain.

NPLEX stores the raw bytes of the W3C Verifiable Credential (VC) as an immutable on-chain audit trail during identity approval. The actual VC validation (signature verification, issuer trust) occurs off-chain before the administrator calls approve_identity. Upon verification, the Registry whitelists the user's IOTA Identity with a specific Role bitmask (1=Institution, 2=Investor, 4=Admin). The approval flow dynamically emits distinct events for new identity approvals (IdentityApproved) versus role updates (IdentityRoleUpdated).

At transaction time, users pass an ephemeral DelegationToken to the smart contracts. The protocol queries the Registry to confirm role authorization (specifically leveraging the public `verify_identity` function, rendering the gate usable by any interacting module), executing the action while keeping sensitive Personally Identifiable Information (PII) entirely off-chain. The raw W3C VC data is stored permanently in the Registry table as a cryptographic audit trail for regulators.

8. EU Regulatory Alignment

The protocol architecture was built from the ground up to foresee and adapt to the current European regulatory landscape:

• Secondary Market Directive (SMD): Facilitates transparent NPL data sharing via immutable Notarization hashes.
• MiCAR: Positions are structured to align with future utility/security token frameworks.
• DLT Pilot Regime: Fully tracks participant identities and prevents unaccounted bearer-asset transfers.

Note: Regulatory alignment is achieved through the protocol's architectural design (DID-gating, immutable audit trails, non-bearer-asset model). Specific regulation-level checks are enforced at the application and governance layers, not directly in the Move smart contracts.

9. Extensibility & Display Standards

The system is inherently upgradeable without requiring proxy contracts. The NPLEXRegistry allows the Administrator to dynamically authorize new executor modules (e.g., add_executor<LTC2>()).

This allows future versions of the platform to introduce new tokenomics—such as complex multi-tranche waterfalls or real estate-backed loan models—plugging seamlessly into the exact same identity, compliance, and notarization infrastructure. All on-chain objects leverage the IOTA Display standard for seamless wallet and explorer rendering.

Furthermore, both main protocol modules (REGISTRY and LTC1) securely enforce the One-Time Witness (OTW) pattern for Publisher claims and Display setups. For maximum indexability and transparency, all system events (29 distinct types) are centralized within a package-private events.move module. The system actively utilizes the public_share_object standard for Display to establish ecosystem-wide open visibility.

10. Contract Lifecycle & Revocation

A contract transitions through three main active phases: Creation, Token Sale, and Recovery & Revenue. (Termination is currently handled off-chain via notarization revocation; a dedicated on-chain termination workflow is planned for a future protocol version.)

• Sales Toggle: After creation, sales default to closed. The NPLEX Administrator must issue a sales toggle authorization. The originator (Institution) then consumes it via toggle_sales, before any investor can purchase tokens.
• Transferring Ownership: Package ownership is transferable via the Ticket System: the Admin authorizes a transfer. This authorization strictly validates that the new owner's DID is approved and holds the ROLE_INSTITUTION bitmask. The current owner, whose DID must match the package's active owner_identity, then calls transfer_ownership to atomically execute the change.

When all debts inside an NPL package are fully recovered, or if legal discrepancies arise, the NPLEX Administrator flags the Notarization as revoked in the Registry. A revoked contract instantly blocks all financial operations — including buy_token, deposit_revenue,withdraw_funding, and crucially, revenue claims (claim_revenue, claim_revenue_owner). toggle_sales (which additionally checks for an Institution DID) and transfer_ownershiprely purely on Ticket System authorization and are not blocked by revocation. (Note: Future protocol versions may introduce granular permission control to allow investor exits during administrative holds.)

Additionally, funding withdrawal and revenue deposits are strictly restricted to the package owner via DID identity matching — only the DID that matches the package's owner_identity can execute these operations.

Tokens continue to exist as cryptographic proof of historical investment, but no further payouts are possible until the contract is un-revoked. Revocation is reversible: the Administrator may call unrevoke_notarization to restore an active contract, re-enabling all financial operations.