The three layers at a glance

Rekord is a stack of three layers. Each layer produces evidence that the next layer consumes, and each layer has one named operator.

  1. Capital and vault execution. Stablecoin vaults and non-rehypothecated credit lines. Operated by Rekord Capital Markets.
  2. AI credit underwriting and verifiable datarooms. Document ingestion, quality control, dataroom packaging and financial spreading in Rekord AI. Built by Rekord AG.
  3. Cryptographic attestation and the proof surface. Hashing, canonical serialization, Merkle batching and on-chain anchoring in Rekord Kloud, read through the Proof Console. Built by Rekord AG.

The layers connect in one direction. A borrower's documents become a hashed dataroom. The dataroom becomes a spread and a scorecard. The scorecard informs a capital decision, and that decision becomes an on-chain transaction. Every NAV update that follows is anchored, so a depositor, an LP or a regulator can trace a position back to the primary documents behind it.

Layer 1: Capital and vault execution

Layer 1 is where capital moves. Rekord Capital Markets operates it, and every action in it settles on a public chain.

Stablecoin vaults

Depositors place USDC or USDT into vaults that follow the ERC-4626 tokenized vault standard and its ERC-7540 asynchronous extension. ERC-4626 gives each vault a standard interface for deposits, share accounting and redemptions. ERC-7540 adds asynchronous requests: a deposit or a redemption is first recorded as a request, and it settles when the vault processes the next NAV update. That model fits private credit, where the underlying loans do not trade on an order book and cannot be priced every block.

The live example is the 9Summits Short Duration Institutional Credit, Powered by Rekord vault (9SicUSDC) on Lagoon Finance. It is deployed on Ethereum Mainnet at 0x6a39fe461278376f61acbbb6759550e24a78a7b2. Anyone can read its share supply, its pending requests and its NAV history directly from the contract. The vault targets competitive USD returns from short-duration institutional credit. Details of the vault product are on the Rekord Vaults page.

Governance and custody controls

The vault's assets sit in a 3/6 Safe multisig at 0x2ec0f23b52f60ce3c6406cf3fd72fb9e28016eff. Three of six signers must approve each transaction. A signer quorum alone still leaves the question of where funds can go, so the Safe also carries a public Zodiac Roles Modifier. The modifier scopes outgoing transfers to a single whitelisted destination: the Fordefi settlement vault at 0xC5a8b7C688aeb508cD19894c12d2f9Ef3ae753D3.

The result is a structural control on where funds can go. The role configuration is on-chain, so an allocator or an auditor can read the permitted destination without a request to the operator.

Non-rehypothecated digital asset credit lines

The second capital product is a credit line against digital assets. A borrower pledges BTC, ETH or staked validator collateral. The collateral stays in segregated custody, and title does not move. It is never lent on, reused or posted as collateral elsewhere. The borrower draws stablecoin liquidity against the pledged position, and the position stays visible for the life of the facility.

Loan-to-value and liquidation mechanics decide how much a borrower can draw and when a position needs more collateral. To model those mechanics on your own numbers, use the crypto LTV and liquidation calculator. Facility terms for a specific borrower are shared under NDA.

Layer 2: AI credit underwriting and verifiable datarooms

Layer 2 turns a borrower's documents into a credit decision that a lender can check line by line. Rekord AG builds it as Rekord AI and the trust layer underneath it.

Borrower ingestion and categorization QC

A borrower uploads documents through the ingestion portal. Each file is classified into one of five document classes:

  • financial statements,
  • bank statements,
  • borrowing base certificates,
  • accounts receivable (AR) aging schedules,
  • legal agreements.

Quality control runs on every file at upload. OCR readability scoring flags scans that are too poor to extract reliably. Each file is hashed with SHA-256, so a duplicate upload is caught even when the file name differs. Drafts, unsigned agreements and blank templates get a quality flag before they reach an analyst. The system also extracts the reporting period and the legal entity from each document, so a mismatched period or an unexpected subsidiary is visible early.

Structured dataroom packaging

Classified files are packaged into a dataroom export: a .zip archive with a manifest.json at its root. The folder taxonomy is deterministic, from 01_Corporate_and_Legal through 07_Tax_and_Compliance, so the same inputs always produce the same structure. The manifest declares schemaVersion: "1.0" and records, for every file, its canonical path, its category, the classification confidence and its SHA-256 fileHash.

A lender or an auditor who receives the archive can recompute each hash and compare it with the manifest. A match shows the file is the one the borrower submitted. To run that check in your browser, use the SHA-256 dataroom verifier.

Deterministic spreading and click-to-verify citations

Rekord AI spreads the borrower's financials and calculates the standard credit metrics:

  • Debt Service Coverage Ratio (DSCR): cash available for debt service divided by scheduled principal and interest,
  • Interest Coverage Ratio: operating earnings divided by interest expense,
  • Debt Yield: net operating income divided by total debt,
  • ABL Borrowing Base availability: eligible receivables and inventory after advance rates and reserves, less outstanding drawings.

The calculations are deterministic. The same inputs always give the same outputs, and the model does not estimate the arithmetic. Every extracted number carries a citation to the exact source document, the page number and the text snippet it came from. An analyst clicks a figure in the spread and sees the line in the original statement. The "Ask the Room" copilot answers questions about the dataroom in plain language, and each answer cites its sources in the same way.

To see how these metrics respond to your own inputs, use the DSCR and borrowing base calculator. Acceptance thresholds belong to each lender's credit policy and stay out of public material.

Layer 3: Cryptographic attestation and the proof surface

Layer 3 makes the output of the first two layers verifiable by people who do not operate them. Rekord AG builds it as Rekord Kloud and the Proof Console.

  • Per-document hashing. Each document is hashed with SHA-256 through crypto.subtle, the browser's WebCrypto interface. The hash is computed before upload, so the borrower holds the same value the platform records.
  • Submission receipts. Each submission produces a cryptographic receipt that lists the files and their hashes. The borrower can print it or download it and keep it as independent evidence of what was submitted and when.
  • Canonical serialization. Structured records such as manifests and scorecards are serialized with RFC 8785, the JSON Canonicalization Scheme, before hashing. Any party that holds the same data computes the same hash.
  • Merkle batch roots. Hashes are aggregated into a Merkle tree, and only the root is anchored. Each record can still be proven individually with a short inclusion path.
  • Append-only anchoring. Roots are anchored on-chain in an append-only sequence. An update adds a new linked version and leaves the earlier versions intact.

The anchor schedule follows the NAV schedule. At each NAV update, LPs, auditors and regulators verify the same state the curator sees, through role-based, read-only access in the Proof Console. Only hashes touch the chain. The underlying documents and position records stay within the operator's perimeter.

Verification lifecycle

The table maps each stage of a facility to the data that enters it, the cryptographic artifact it produces, the entity that operates it and the surface where a third party verifies it.

Operating separation

The split between the two entities is deliberate. Rekord AG builds and runs software: Rekord AI, the dataroom trust layer, Rekord Kloud and the Proof Console. Rekord AG provides infrastructure. It does not hold depositor funds.

Rekord Capital Markets operates the capital. It runs the vaults and the digital asset credit lines, signs settlement transactions within the limits that the Safe and the Roles Modifier enforce, and publishes NAV.

Verification stays with the people who rely on the record. Borrowers keep their own receipts. Lenders and auditors re-hash datarooms on their own machines. Depositors, LPs and regulators read the vault contracts on Ethereum and check anchored NAV states in the Proof Console. For treasuries, funds and allocators who want to review the structure in detail, see Rekord for Institutions.

Frequently asked questions

Which entity operates the vaults, and which entity builds the software?

Rekord Capital Markets operates the vaults and the digital asset credit lines: it deploys capital, settles positions and publishes NAV. Rekord AG builds the software: Rekord AI for underwriting and datarooms, and Rekord Kloud with the Proof Console for attestation. Rekord AG provides infrastructure and does not hold depositor funds.

What does "non-rehypothecated" mean for a pledged BTC or ETH credit line?

The pledged BTC, ETH or staked validator collateral stays in segregated custody under the borrower's name. Title does not move, and the collateral is never lent on, reused or posted elsewhere by the lender. The borrower receives a credit line against it, and the collateral position stays visible for the life of the facility.

How does the Zodiac Roles Modifier restrict what the Safe can do?

The vault's 3/6 Safe needs three of six signers to approve a transaction. A public Zodiac Roles Modifier on the Safe scopes outgoing transfers strictly to one whitelisted destination: the Fordefi settlement vault. The role configuration is public, so anyone can read it on Ethereum Mainnet.

What does manifest.json contain, and how do I verify a dataroom against it?

Each dataroom export is a .zip with a manifest.json (schemaVersion "1.0"). For every file the manifest records its canonical path, its category, the classification confidence and its SHA-256 fileHash. To verify, recompute the SHA-256 of each file in the archive and compare it with the fileHash in the manifest. Any difference shows that the file changed after packaging.

Why canonicalize JSON with RFC 8785 before hashing?

Two JSON documents can carry the same data with different key order, spacing or number formatting, and each variant gives a different hash. RFC 8785 (the JSON Canonicalization Scheme) defines one byte-exact form for the same data. Rekord serializes scorecards and manifests in that form before hashing, so any party that holds the data computes the same hash.

What goes on-chain, and what stays off-chain?

Only hashes go on-chain. Rekord Kloud anchors SHA-256 hashes and Merkle batch roots to the chain. Financial statements, bank data, legal agreements and position records stay within the operator's perimeter. The on-chain record proves that a given document or state existed at a given time and has not changed since.

Check the record yourself.