The Waterfall Engine

The cornerstone of the protocol is its capital hierarchy. During a claim event, the `triggerCatastrophe` function in `HPIVVault.sol` executes a strict sequential loss absorption cascade to protect Senior investors.

// Snippet from HPIVVault.sol : The Claim Engine
function triggerCatastrophe(uint256 claimAmount) external onlyRole(ORACLE_ROLE) nonReentrant {
    require(status == VaultStatus.ACTIVE || ... , "Invalid state");
    uint256 remainingClaim = claimAmount;

    // STEP 1: Insurer Capital (First Loss)
    if (sponsorFirstLossCapital >= remainingClaim) {
        sponsorFirstLossCapital -= remainingClaim;
        remainingClaim = 0;
    } else {
        remainingClaim -= sponsorFirstLossCapital;
        sponsorFirstLossCapital = 0;
    }

    // STEP 2: Premium Reserve (Yield acts as a buffer)
    if (remainingClaim > 0) {
         if (premiumReserve >= remainingClaim) {
            premiumReserve -= remainingClaim;
            remainingClaim = 0;
        } else {
            remainingClaim -= premiumReserve;
            premiumReserve = 0;
        }
    }

    // STEP 3: Junior Tranche (ERC-20)
    if (remainingClaim > 0) {
        if (juniorPrincipal >= remainingClaim) {
            juniorPrincipal -= remainingClaim;
            juniorLossPercent = (remainingClaim * 1e18) / (juniorPrincipal + remainingClaim);
            remainingClaim = 0;
        } else {
            uint256 loss = juniorPrincipal;
            juniorPrincipal = 0;
            juniorLossPercent = 1e18; // 100% loss
            remainingClaim -= loss;
        }
    }

    // STEP 4: Senior Tranche (Protected ERC-4626)
    if (remainingClaim > 0) {
        if (seniorPrincipal >= remainingClaim) {
            seniorPrincipal -= remainingClaim;
            seniorLossPercent = (remainingClaim * 1e18) / (seniorPrincipal + remainingClaim);
            remainingClaim = 0;
        } else {
            seniorPrincipal = 0; // Total Default
            seniorLossPercent = 1e18;
        }
    }

    // Process claim and lock the vault
    IERC20(asset()).transfer(address(0xdead), claimAmount);
    status = VaultStatus.TRIGGERED;
}

Yield Splitting Model

Yield is generated from the Insurance Premium (`premiumReserve`) paid upfront by the Sponsor. The distribution is deliberately asymmetric to create leverage for the Junior tranche while ensuring stable returns for the Senior tranche.

On-Chain Junior Equity Calculation

The Junior tranche withdrawal (`withdrawJunior`) uses the internal `_calculateJuniorEquity` function to precisely determine their remaining principal plus their proportional share of the premium :

function _calculateJuniorEquity() internal view returns (uint256) {
    if (juniorPrincipal == 0) return 0;
    if (status == VaultStatus.TRIGGERED && juniorPrincipal == 0) return 0;

    // Junior retrieves remaining principal + share of premium
    uint256 totalPrincipal = seniorPrincipal + juniorPrincipal;
    if (totalPrincipal == 0) return 0;

    uint256 juniorShareOfPremium = (premiumReserve * juniorPrincipal) / totalPrincipal;
    return juniorPrincipal + juniorShareOfPremium;
}

Anti-Inflation Attack Defense

Standard ERC-4626 Vaults are vulnerable to "Donation Attacks" (Inflation Attacks), where a malicious actor manipulates the initial exchange rate by donating assets to the Vault, thereby stealing subsequent deposits. Moeba Protocol mathematically neutralizes this flaw during the vault's initialization.

// Snippet from initializeVault() in HPIVVault.sol
// ANTI-INFLATION PROTECTION (DONATION ATTACK)
// We mint 1000 shares of Senior and Junior to the 0xdead address (Burn).
// This permanently locks the initial denominator and prevents rounding attacks.
// These 1000 wei come directly from the Insurer's capital (negligible security cost).

// Lock Senior Dead Shares
_mint(address(0xdead), 1000);
seniorPrincipal += 1000;

// Lock Junior Dead Shares
juniorToken.mint(address(0xdead), 1000);
juniorPrincipal += 1000;

// Adjust effective sponsor capital
sponsorFirstLossCapital -= 2000;

Risk Categories & Triggers

The Moeba infrastructure is risk-agnostic. Vaults can cover any event verifiable by deterministic data feeds or physical IoT sensors. The dApp natively categorizes these into specific deployable templates.

UMA Optimistic Oracle

Moeba Protocol utilizes the UMA Optimistic Oracle (OO) to securely bring real-world data on-chain. Rather than relying on rigid price feeds, UMA allows any verifiable truth (even subjective audits) to be asserted on-chain.

• 1. Assertion : An actor asserts that a specific event occurred (e.g., "Hurricane reached Category 4" or "Forensic audit confirmed a 40% revenue drop").
• 2. Dispute Window : A liveness period opens. If no one disputes the claim by providing contrary evidence, the data is taken as mathematical truth and the claim is validated.
• 3. DVM Resolution : If disputed, UMA token holders vote to resolve the truth via the decentralized Data Verification Mechanism.

VUSA & DLT Law

Moeba bridges DeFi with institutional finance by operating strictly within the cutting-edge Swiss regulatory framework supervised by FINMA.

KYB/KYC On-Chain Registries

To comply with the Swiss Anti-Money Laundering Act (AMLA) and enforce the "Travel Rule", Moeba operates as a **Permissioned DeFi protocol**. Both Sponsors and Investors must be verified.

1. KYB for Sponsors (Insurers)

Insurers must submit a registration request to the `HPIVFactory.sol` containing their Legal Entity name and an IPFS hash of their KYB documentation. Only approved Sponsors can deploy Vaults.

// Snippet from HPIVFactory.sol : Sponsor Whitelist
struct SponsorRequest {
    string companyName;  // Legal entity name
    string kybHash;      // IPFS Hash containing proof
    RequestStatus status;
    uint256 requestDate;
}

function registerSponsor(string memory _companyName, string memory _kybHash) external {
    require(!isWhitelistedSponsor[msg.sender], "Already whitelisted");
    // ... logic to request approval
}

2. KYC for Investors (Liquidity Providers)

Investors must be whitelisted in the centralized `HPIVCompliance.sol` registry. This check is injected directly into the `_update` function of the Vault tokens, freezing any Peer-to-Peer transfer to an unverified address.

// Snippet from HPIVJuniorToken.sol & HPIVVault.sol
function _update(address from, address to, uint256 value) internal virtual override {
    // Blocks P2P transfers if receiver is not KYC'd
    if (from != address(0) && to != address(0)) {
        require(
            ICompliance(complianceModule).isAllowed(to),
            "Receiver must be KYC whitelisted"
        );
    }
    super._update(from, to, value);
}

Sponsor Dashboard & Vault Creation

The Moeba dApp provides a dedicated "Sponsor Dashboard" for whitelisted insurers to deploy and manage their parametric products.

Marketplace & Portfolio Tracking

Investors interact with Moeba through a robust Marketplace and a detailed Portfolio manager to track their positions and claims.