Plyra documentation

This quick start is for the onchain settlement layer (track two). If you only want to structure and validate a pool, you do not need any of these steps: see Validate your first prospectus in 60 seconds instead.

The fastest way to understand Plyra is to run it on a real deal. You need no wallet, no testnet, and no signup. Everything below runs in the Workbench against the deterministic engine.

The engine takes a pool description and returns a defensible structure using standard structured-credit math. Nothing here is a black box: each number is a closed-form calculation off your inputs and the asset-class defaults, so a skeptic can reproduce every figure by hand. The steps below are the methodology in plain language.

Document-vs-engine is the validation step. When you paste a prospectus, Plyra extracts the deal's claimed terms exactly as written, then runs its own deterministic structure on the same pool. The diff compares the two side by side: what the document claims, what the engine independently produced, and whether they agree. It is a second opinion on a deal's stated structure, not a rewrite of it.

The same engine that powers the Workbench is reachable as a set of HTTP endpoints, so a fintech can wire pre-deal structuring and prospectus validation directly into its own origination pipeline instead of using the dapp. All three endpoints accept a JSON body via POST. The structure and prospectus endpoints are pure functions of their input and return JSON; the memo endpoint streams. Rate limits apply per IP (the prospectus extractor is the tightest, since it is the heaviest call); a 429 means wait a minute and retry.

POST /api/analyst/structure

Send a pool description; receive the deterministic structure. The body is { pool } where pool is a PoolInput(asset class, pool size, weighted coupon, term, expected default, recovery, and so on; unstated fields fall back to mid-market defaults). The response is the full AnalysisResult JSON: the Senior / Mezzanine / Equity stack with attachment points, per-tranche risk-adjusted return, breakeven loss rates, DV01 and modified duration, and the pool-level expected loss. Because the engine is deterministic, the same pool always returns the same structure.

curl -X POST https://app.plyra.io/api/analyst/structure \
  -H "Content-Type: application/json" \
  -d '{
    "pool": {
      "assetClass": "solar-loans",
      "poolSize": 50000000,
      "numLoans": 200,
      "grossCouponPct": 8.5,
      "termYears": 20,
      "annualDefaultRatePct": 6.0,
      "recoveryRatePct": 45
    }
  }'
# -> AnalysisResult JSON: tranches, expectedLoss, breakeven, dv01, duration

POST /api/analyst/prospectus

Send raw offering-document text; receive the extracted claim and the diff. The body is { text }. The response is { claim, diff }: claim is the deal's stated terms extracted exactly as written (a ProspectusClaim, with n/a for any field the document does not provide), and diff is the field-by-field comparison against the engine (a ProspectusDiff carrying the overall agreement flag and per-field results, the same shape the Workbench renders). See Reading the diff for the tolerances.

curl -X POST https://app.plyra.io/api/analyst/prospectus \
  -H "Content-Type: application/json" \
  -d '{ "text": "Class A Notes ... 80.0% ... Class B ... 12.0% ... residual ..." }'
# -> { claim, diff } : extracted terms + field-by-field agreement

POST /api/analyst

Send a pool and its computed analysis; receive a streamed credit memo. The body is { pool, analysis } (typically the same AnalysisResult returned by the structure endpoint). The response is a server-sent-events stream of the memo text as it is written: a concise institutional credit memo grounded only in the supplied numbers, never recomputed or invented. Read it as an SSE stream and append each chunk.

curl -N -X POST https://app.plyra.io/api/analyst \
  -H "Content-Type: application/json" \
  -d '{ "pool": { /* PoolInput */ }, "analysis": { /* AnalysisResult */ } }'
# -> text/event-stream: credit memo, streamed chunk by chunk

The engine is a structuring and stress-testing tool, not a rating agency, an underwriter, or an adviser. Knowing where its assumptions come from is part of trusting its output. The points below are the boundaries.

Forge tranche positions are ERC-20 tokens. Wallets do not always discover testnet tokens automatically, so you may need to import the Senior, Mezzanine, or Equity token address manually after investing.

Full deployment metadata is maintained in the repository docs and SDK address map.

Plyra is designed to support Avalanche eERC privacy as an encrypted tranche-token mode for future Forge vaults. The first target is private Senior, Mezzanine, and Equity position balances while keeping aggregate vault analytics and auditor-ready compliance paths intact.

The @meridianprotocol/sdk package is the onchain integration layer for the settlement protocol: addresses, ABIs, and constants for calling Forge, Shield, Nexus, and Trade with viem. It is distinct from the Analyst API, which is the HTTP surface for the pre-deal engine and needs no wallet or chain.

npm install @meridianprotocol/sdk viem

import { createPublicClient, http, parseUnits } from "viem";
import { avalancheFuji } from "viem/chains";
import { ADDRESSES, ForgeFactoryAbi, ForgeVaultAbi, ERC20Abi } from "@meridianprotocol/sdk";

const client = createPublicClient({
  chain: avalancheFuji,
  transport: http("https://api.avax-test.network/ext/bc/C/rpc"),
});

const addresses = ADDRESSES[43113];

const vaultCount = await client.readContract({
  address: addresses.forgeFactory,
  abi: ForgeFactoryAbi,
  functionName: "vaultCount",
});

// Before investing, approve mUSDC to the selected ForgeVault.
await walletClient.writeContract({
  address: addresses.mockUSDC,
  abi: ERC20Abi,
  functionName: "approve",
  args: [vaultAddress, parseUnits("1000", 18)],
});

await walletClient.writeContract({
  address: vaultAddress,
  abi: ForgeVaultAbi,
  functionName: "invest",
  args: [0, parseUnits("1000", 18)], // 0 = Senior
});