Concepts

How an action runs

A party signs a NEAR transaction. The rules contract checks it, runs the books inside the enclave, checks the answer and stores what comes back.

Nine steps

Take the agent requesting interest. It signs a NEAR transaction that calls request_interest on ledger.paridesk.testnet with the total it typed.

The rules contract

  1. Is the caller the agent?
  2. One action at a time (a lock).
  3. Run the one pinned build of the enclave program, and tell it who called.

The books, inside the Intel TDX enclave on OutLayer

  1. Open the books from encrypted storage.
  2. Apply the deal’s rules, or refuse.
  3. Save the books; seal one envelope per party and hash the facts in it. Hand back the new fingerprint, the public totals, and one sealed envelope and one commitment per party.

The rules contract again

  1. Check the money rules again, without trusting the enclave.
  2. Store the fingerprint, the envelopes and the commitments.
  3. Pay out test USDC (withdrawals), and tell the party: done, or refused.

Steps 3 to 6 are one NEAR transaction: the contract calls OutLayer, waits (NEAR’s yield/resume), and gets the answer in a callback.

What comes back

A fingerprint of the new books (a sha256, with 32 fresh random bytes hashed in) and, for each party, one sealed envelope, encrypted so only that party can open it, and one commitment: a salted hash of the facts inside that envelope. The contract stores all three. A party can use the commitment to prove one fact from its envelope.

Secrets never touch the chain in the clear

Anything secret a party sends (a trade’s buyer, size and price; the DQ list; the opening positions) is sealed to the enclave’s public key before it goes into a transaction. Lender payments are credits inside the books, not token transfers, so no per-lender amount ever appears on chain.

An answer that comes late counts for nothing

NEAR lets a contract wait about two minutes for the enclave. If no answer comes, the contract records “the enclave did not answer; nothing changed”, releases the lock and gives back any tokens sent with the action.

The contract numbers every request and names the fingerprint it holds. The enclave builds only on the books with that fingerprint, and refuses a request with an older number than one it has already answered. So an enclave run that finishes after the wait changes nothing, and the action can simply be sent again. The scripts do that by themselves, up to four times; the app says what happened and asks you to press the button again.

Why this needs NEAR

  • A contract can call an enclave and get the answer back in the same transaction. OutLayer runs WASM inside Intel TDX with encrypted storage that persists between runs, and a NEAR contract calls it and resumes with the result (yield/resume). That is what lets the rules sit on chain while the books stay private. The contract, not a server, decides when the books run.
  • Keys that nobody holds. The key that encrypts the books and the enclave’s own X25519 key are derived by OutLayer’s keystore for this project and the contract that called it. The program never sees the storage key, the developer has neither, and a run started by anyone but the rules contract gets a different key.
  • Named accounts for every role. The contract’s role checks and the enclave’s views are keyed by names a person can read.
  • One token transfer that also runs the books. The borrower pays with ft_transfer_call (NEP-141); the contract records the public amount and the enclave credits the books in the same transaction. If the books refuse, the tokens go back.
  • An agent that is two of three, with no change to the contract. A NEAR account can be a Sputnik DAO. Name the DAO as the deal’s agent and every agent action becomes a proposal that two of three operators must approve. See The agent, two of three.

Next on NEAR: withdrawals through NEAR’s confidential intents, so that even those amounts are hidden.