Funding & withdrawals

Layrs moves value in and out of the private ledger through a deposit-and-sweep flow on the way in, and an enclave-authorized, screened payout flow on the way out. Balances that trade inside the attested enclave are never credited on optimistic signals: money is only recognized after it has reached finality in the protocol's pooled custody, and payouts are only released after the enclave signs an authorization for them.

This page describes both directions, the assets and chains involved, and how destination data is protected.

Assets and chains

Layrs settles on two chains:

• Horizen Mainnet — chainId 26514, explorer horizen.calderaexplorer.xyz.
• Base — chainId 8453, explorer basescan.org.

Two assets are supported for funding:

Asset	Chain	Decimals	Notes
USDC	Base	6	Native USDC on Base.
ZEN	Base	18	ZEN is native on Base.
ZEN	Horizen	18	ZEN is an OFT (LayerZero Omnichain Fungible Token) on Horizen.

ZEN is native on Base and exists as an OFT on Horizen. The production live market path is ZEN-only today, so ZEN is the asset that actually flows through the trading ledger; USDC (Base) is a supported funding asset.

Depositing

Deposits follow a three-step path: a one-time address, a sweep into pooled custody, and a credit that only lands after pool-side finality.

1. Generate a one-time deposit address. Each deposit intent produces a freshly generated deposit address dedicated to that request. You initiate this through POST /v1/funding/deposits and can poll status via GET /v1/funding/deposits/{depositId}.
2. Send funds; the backend sweeps into the pool. When funds arrive at the one-time address, the backend sweeps them into the LayrsPool. Arrival at the deposit address alone does not create a balance.
3. Credit after pool-side finality. Your private-ledger balance is credited only after pool-side finality — never on mere arrival at an externally owned account (EOA). This is the boundary that matters: an EOA seeing the funds is not a credit; finality inside the pool is.

one-time deposit address  ->  backend sweep into LayrsPool  ->  credit to private ledger
                                                               (only after pool-side finality)

Because the private ledger lives inside the attested enclave, the credited balance becomes part of the enclave's available balance for that opaque private-user identity, alongside the held, collateral, fee, and position balances the enclave tracks internally.

ZEN across chains (Base to Horizen)

ZEN can originate on Base and be used on Horizen. That movement uses Stargate / LayerZero OFT bridging:

• A Base-ZEN deposit bridges to a backend-controlled receiver.
• That is then followed by a verified same-chain deposit into the Horizen LayrsPool.

In other words, the cross-chain leg (Base to Horizen via the OFT) and the pool deposit leg are distinct: the OFT bridge delivers ZEN to a receiver the backend controls, and only a verified same-chain deposit into the Horizen LayrsPool results in a pool-custodied balance eligible for crediting.

Withdrawing

Withdrawals are gated on the enclave, not the host. A credited balance cannot leave until the enclave signs an authorization for it, the coordinator screens it, and a dedicated signer executes the payout from the pool.

The user-path sequence is:

1. Credited balance. The withdrawal draws against a balance already credited to the private ledger.
2. Enclave-signed withdrawal authorization. The enclave produces a signed withdrawal authorization. The host cannot fabricate this — the parent/host process cannot submit an administrative operation without the Ed25519 operator key compiled into the enclave image (EIF).
3. Coordinator screening. The authorization passes through coordinator screening before any funds move.
4. Pool payout by the dedicated ledger signer. The payout is released from the pool by the dedicated ledger signer — a role separate from the enclave that authorized it.

credited balance
  -> enclave-signed withdrawal authorization
  -> coordinator screening
  -> pool payout by the dedicated ledger signer

You initiate a withdrawal with POST /v1/funding/withdrawals and track it with GET /v1/funding/withdrawals/{withdrawalId}.

Destination confidentiality

Withdrawal destinations are envelope-encrypted using KMS and stored as a destination_ciphertext. The plaintext destination is not held in the clear alongside the withdrawal record; the ciphertext form is what persists.

This is consistent with the broader Layrs posture that plaintext never reaches an API container, database, or log for private order flow — destinations receive the same envelope-encryption treatment rather than being exposed in host-side storage.

Why balances aren't credited early

The two guarantees worth internalizing:

• On the way in: a balance exists only after pool-side finality, not when a deposit address or EOA first observes the funds. The sweep into LayrsPool and finality are prerequisites for a credit.
• On the way out: funds leave only after an enclave-signed authorization, coordinator screening, and a payout executed by the dedicated ledger signer. Three distinct steps, no single one of which is sufficient alone.

These steps are described as the funding and withdrawal flow of the protocol. This page does not assert anything about the degree of automation, throughput, or timing of any individual step beyond the ordering above.

Endpoints

Method	Path	Purpose
POST	/v1/funding/deposits	Create a deposit intent (one-time address).
GET	/v1/funding/deposits/{depositId}	Read deposit status.
POST	/v1/funding/withdrawals	Request a withdrawal.
GET	/v1/funding/withdrawals/{withdrawalId}	Read withdrawal status.

All of the above are served from the public API base https://api.layrs.xyz.