Forem: ayush singh

# [Tutorial] Confidential Asset Management on Midnight

ayush singh — Wed, 13 May 2026 10:13:54 +0000

📁 Source: Midnight-dApps/confidential-asset-management

The TradFi-to-DeFi pipeline has been stuck on one specific question for half a decade: how do you give LPs the programmability and speed of public chains without doxxing the entire allocator book and giving away the GP's edge?

Tribute, Enzyme, dHedge, and every other on-chain fund I've looked at has the same gap. They publish the cap table, they publish the holdings, and increasingly they publish the strategy. That's fine for retail trying their luck with $100. It's a deal-breaker for a real $100M fund.

Midnight is the first chain where this trade-off actually splits the right way. AUM can be public. ROI can be public. Per-LP allocations stay private. Strategy stays off-chain. Auditors get verifiable counter values; LPs get the privacy they need to participate.

This dApp is a working demonstrator of that model. ~120 lines of Compact, ~600 lines of React, four roles wired in (GP, LP, auditor, observer). I'll walk through the contract piece by piece, then the frontend, then what's missing for production.

Use cases this could actually serve

Family-office managed funds — single-family offices pool capital across cousins, in-laws, and siblings. Today these are private LP agreements with annual paper statements. Move them on-chain on Midnight and you keep the privacy from outsiders, give every family branch independent verifiability of pool performance, and settle distributions same-day instead of quarterly.
Crypto-native hedge funds with TradFi LPs — a quant fund that takes capital from both crypto-native LPs and traditional allocators. The crypto LPs want on-chain transparency; the TradFi LPs require a privacy guarantee before they'll allocate. Today the fund has to pick one. With this contract, both can sit in the same vehicle.
Tokenised emerging-markets credit funds — high-yield credit funds where the LP list itself is sensitive (sanctions exposure, reputation, jurisdictional issues). Aggregate AUM and yield can be public so the protocol stays auditable; per-LP positions are commitments in a Merkle tree.

Prerequisites

Node 20+
Lace or 1AM, on Midnight Preprod
tNIGHT + tDUST from the Preprod faucet
Docker
The Compact compiler

curl --proto '=https' --tlsv1.2 -LsSf \
  https://github.com/midnightntwrk/compact/releases/latest/download/compact-installer.sh | sh

Privacy/auditability — where the line sits

The interesting design decision in this dApp is which fields are public versus private. There's no single right answer; it depends on what the regulator needs to see, what the LPs want hidden, and what the GP needs to keep secret.

Here's how I drew the lines:

Field	Public?	Why
`manager`	Yes	Sealed at deploy; identifies who can act as GP
LP commitments	Tree only	Chain sees leaves, never wallets
LP allocation amount	Public	Added to `aum`; the chain needs to verify solvency
`aum`	Yes	Public AUM for compliance and LP comfort
`reportedRoiBp`	Yes	LP and regulator verifiability of performance
Per-LP holdings ratio	Off-chain	GP keeps these books
Strategy	Off-chain	The GP's edge
Payout amounts	Public	Solvency requires it
Payout recipients	Private	Same pattern as the dividend dApp

That last row is the key insight: the chain learns "an LP claimed 60,000 for period 2026-05" without learning which LP. The trade is "amount public, identity private" — the opposite of most on-chain funds today.

This is the opposite trade-off of every existing on-chain fund product. Tribute, Enzyme, et al. leak per-wallet holdings on a public chain. Off-chain funds leak nothing on-chain. Midnight finds the third option.

The contract

Full source: contracts/Contract.compact.

Ledger state

pragma language_version 0.22;
import CompactStandardLibrary;

export sealed ledger manager: Bytes<32>;

export ledger lpCommitments: HistoricMerkleTree<10, Bytes<32>>;
export ledger payoutNullifiers: Set<Bytes<32>>;

export ledger aum: Uint<64>;
export ledger reportedRoiBp: Uint<64>;

export ledger totalLps: Counter;
export ledger totalPayouts: Counter;

The ledger has six pieces of state:

manager is the GP's public key, sealed at deploy. Every privileged circuit checks manager == publicKey(callerSk). There is no admin handover circuit — for a production system you'd add a two-step proposeNewManager + acceptManager flow with a time-lock.
lpCommitments is the LP cap table. Each leaf is H(lpSk, fundId). Depth 10 supports up to 1024 LPs, which is fine for any real fund (most institutional funds cap out at 200–300 LPs by SEC rules anyway).
payoutNullifiers is the anti-double-claim set. A nullifier is H(lpSk, fundId, period). Two claims with the same triple produce the same nullifier; the second one bounces.
aum is the public assets-under-management counter. Both admitLp (which increments) and redeemLp / claimPayout (which decrement) touch it.
reportedRoiBp is the per-period ROI in basis points. 1200 = +12.00%. Public so LPs can verify the GP is reporting what they claim, and so external observers can rank the fund's performance.
The two counters are public dashboard fodder.

Witnesses

witness localSecretKey(): Bytes<32>;
witness findLpPath(commit: Bytes<32>): MerkleTreePath<10, Bytes<32>>;

Same pattern as the other two dApps in this repo: one witness for the caller's secret, one for the Merkle path. The TypeScript side that resolves them:

export const witnesses = {
  localSecretKey: ({ privateState }) => [privateState, privateState.secretKey],
  findLpPath: ({ privateState, ledger }, commit) => {
    const path = ledger.lpCommitments.findPathForLeaf(commit);
    if (!path) throw new Error('LP commitment not found in tree');
    return [privateState, path];
  },
};

The Midnight runtime calls these during proof generation. The path becomes part of the ZK proof; the chain only verifies the resulting root match.

Constructor

constructor(managerSk: Bytes<32>) {
    manager = disclose(publicKey(managerSk));
}

circuit publicKey(sk: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<2, Bytes<32>>>(
        [pad(32, "fund:pk:v1"), sk]
    );
}

The deployer passes their secret key as a witness argument. We hash it (domain-separated with "fund:pk:v1" so it doesn't collide with public keys in other Midnight dApps using the same wallet) and seal the result into manager.

`getLpCommitment(sk, fundId)` — off-chain helper

circuit lpCommit(sk: Bytes<32>, fundId: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<3, Bytes<32>>>(
        [pad(32, "fund:lp:v1"), fundId, sk]
    );
}

export circuit getLpCommitment(sk: Bytes<32>, fundId: Bytes<32>): Bytes<32> {
    return lpCommit(sk, fundId);
}

lpCommit is the private helper. getLpCommitment is the public wrapper the frontend can call as a pure circuit — no on-chain tx, just a hash.

The same wallet always produces the same commitment for a given fund, which is what makes "lose your wallet seed, lose your LP identity" the security model. Same wallet across two funds produces different commitments because fundId is part of the hash, which is exactly what you want.

`admitLp(commit, allocation)` — GP only

export circuit admitLp(holderCommit: Bytes<32>, allocation: Uint<64>): [] {
    const sk = localSecretKey();
    assert(manager == disclose(publicKey(sk)), "Not the fund manager");
    lpCommitments.insert(disclose(holderCommit));
    aum = (aum + allocation) as Uint<64>;
    totalLps.increment(1);
}

The GP onboards an LP by inserting their commitment and bumping the AUM. Three observations:

The allocation is disclosed — it has to be, because we add it to the public aum. If we tried to keep allocations private, the AUM counter wouldn't be credible (the GP could lie about the sum).
The chain learns the allocation but not who. It's "5 million was added by an LP whose commitment is somewhere in the new tree." Nobody can tell which leaf is the 5M vs the 50M.
The off-chain bookkeeping is on the GP. They need to remember "commitment X is worth 5M, commitment Y is worth 50M" so they can compute payouts correctly. The contract has no way of enforcing that — it trusts the GP on per-LP weighting.

This is a deliberate trade-off. Putting per-LP allocations on-chain (even as commitments) would either reveal them or require a full SNARK over the sum, which gets expensive at scale.

`reportRoi(roiBp)` — GP only

export circuit reportRoi(roiBp: Uint<64>): [] {
    const sk = localSecretKey();
    assert(manager == disclose(publicKey(sk)), "Not the fund manager");
    reportedRoiBp = roiBp;
}

Sets the public ROI in basis points. 1200 = +12.00%. Anyone can read this off the indexer.

The contract doesn't verify the ROI matches the AUM movement — that's by design. In a real fund, the GP signs off on a quarterly NAV from an admin (State Street, Northern Trust, et al.), and the on-chain ROI is the externally-attested number. You could build a full audit-chain on top (require a quarterly hash of the admin's report), but that's outside the MVP.

`redeemLp(commit, allocation)` — GP only

export circuit redeemLp(holderCommit: Bytes<32>, allocation: Uint<64>): [] {
    const sk = localSecretKey();
    assert(manager == disclose(publicKey(sk)), "Not the fund manager");
    assert(aum >= allocation, "Allocation exceeds AUM");
    aum = (aum - allocation) as Uint<64>;
}

The GP can process an LP exit. Note we do not remove the commitment from the historic Merkle tree — that's because proofs against older roots are still valid in Compact's HistoricMerkleTree, so removing leaves would break already-issued proofs.

For a real partial-redemption flow you'd pair this with a per-LP redemption nullifier set, so the same LP can only redeem once per cycle.

`proveLp(fundId)` — LP, no-claim variant

export circuit proveLp(fundId: Bytes<32>): Boolean {
    const sk = localSecretKey();
    const commit = lpCommit(sk, fundId);
    const path = findLpPath(commit);
    assert(
        lpCommitments.checkRoot(disclose(merkleTreePathRoot<10, Bytes<32>>(path))),
        "Not an LP of this fund"
    );
    return disclose(true);
}

A standalone "I'm an LP of this fund" proof, no payout side-effect. Useful for:

LP-only Discord channels that gate access on this proof
Compliance attestations ("I am a qualified investor in fund X")
Authentication flows that don't want passwords

The chain sees one tx; an observer learns "some LP of this fund authenticated." No way to map back to the wallet.

`claimPayout(fundId, period, amount)` — LP

export circuit claimPayout(fundId: Bytes<32>, period: Bytes<32>, amount: Uint<64>): Boolean {
    const sk = localSecretKey();
    const commit = lpCommit(sk, fundId);
    const path = findLpPath(commit);
    assert(
        lpCommitments.checkRoot(disclose(merkleTreePathRoot<10, Bytes<32>>(path))),
        "Not an LP of this fund"
    );

    const nul = payoutNullifier(sk, fundId, period);
    assert(!payoutNullifiers.member(disclose(nul)), "Payout already claimed for this period");
    assert(aum >= amount, "Payout exceeds AUM");

    payoutNullifiers.insert(disclose(nul));
    aum = (aum - amount) as Uint<64>;
    totalPayouts.increment(1);

    return disclose(true);
}

This is the core LP action. Steps:

Recompute the LP's commitment.
Ask the witness for the Merkle path.
Assert the path roots to a tree the contract has historically had.
Compute the nullifier for (sk, fundId, period) and assert it hasn't been used.
Assert solvency — the AUM has to be large enough for the requested amount.
Side effects: insert the nullifier, deduct from AUM, bump payout counter.

The LP supplies amount themselves. They compute it off-chain by multiplying their private allocation by the public ROI. The contract doesn't enforce that the math is correct — it only checks solvency. In a real system you'd either:

Have the GP submit per-LP payouts (slower, more centralised)
Use a more sophisticated SNARK that proves amount == allocation * (1 + roi) without revealing allocation

Both have engineering cost. The MVP trusts the LP to compute their payout honestly, which works fine for small consortiums and breaks down for adversarial LPs in larger funds.

`payoutNullifier(sk, fundId, period)` — private helper

circuit payoutNullifier(sk: Bytes<32>, fundId: Bytes<32>, period: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<4, Bytes<32>>>(
        [pad(32, "fund:nul:v1"), fundId, period, sk]
    );
}

Four inputs in the hash: domain, fundId, period, secret. Different period → different nullifier → fresh claim allowed. Same period → same nullifier → claim rejected. The same LP can claim across funds without any cross-fund linkage because fundId is in the hash.

Frontend wiring

Same structural pattern as the other two dApps in this repo. The router has four protected routes:

<Routes>
  <Route path="/"       element={<HomePage />} />
  <Route path="/deploy" element={<RequireWallet><DeployPage /></RequireWallet>} />
  <Route path="/admit"  element={<RequireWallet><AdmitPage /></RequireWallet>} />
  <Route path="/report" element={<RequireWallet><ReportPage /></RequireWallet>} />
  <Route path="/payout" element={<RequireWallet><PayoutPage /></RequireWallet>} />
</Routes>

RequireWallet redirects to / if the wallet isn't attached. No deep-linking around the wallet gate.

Wallet → role key

const APP_SALT = 'confidential-asset-management-v1';

export async function deriveRoleKey(shieldedCoinPublicKey, role) {
  const master = await deriveKeyFromPassword(APP_SALT, shieldedCoinPublicKey);
  return deriveKey(master, `fund:${role}`);
}

Roles are 'lp' and 'manager'. The same wallet can act as both a GP of fund A and an LP of fund B — they get different role keys, derived deterministically from the same wallet seed. This is exactly what a family office that runs its own fund and allocates to others would need.

The provider bundle

src/lib/midnight.ts centralises the providers so the page files don't repeat themselves:

export async function buildProviders(opts) {
  const zkConfig = new FetchZkConfigProvider(`${CONTRACT_PATH}/managed/fund/keys`, fetch.bind(window));
  return {
    privateStateProvider: levelPrivateStateProvider({ privateStateStoreName: opts.privateStateStoreName }),
    publicDataProvider:   indexerPublicDataProvider(INDEXER_HTTP, INDEXER_WS),
    zkConfigProvider:     zkConfig,
    proofProvider:        httpClientProofProvider(PROOF_SERVER, zkConfig),
    walletProvider:       { /* getCoinPublicKey, balanceTx adapter */ },
    midnightProvider:     { /* submitTx adapter */ },
  };
}

export async function loadCompiledContract() {
  const contractPath = CONTRACT_PATH + '/managed/fund' + '/contract/index.js';
  const contractModule = await import(/* @vite-ignore */ contractPath);
  const cc = CompiledContract.make('fund', contractModule.Contract);
  const ccW = CompiledContract.withWitnesses(cc, witnesses);
  return {
    contractModule,
    finalContract: CompiledContract.withCompiledFileAssets(ccW, `${CONTRACT_PATH}/managed/fund`),
  };
}

The string-concat for contractPath is on purpose — Vite 8's static import-analysis tries to resolve template literals at build time, which fails if the contract isn't compiled yet. String concatenation defeats that analysis and lets the import resolve at runtime. Same approach the upstream midnight-apps/fullstack-dapp uses.

Submitting a circuit call

Every action page (Admit, Report, Payout, Deploy) follows the same shape:

const providers = await buildProviders({ /* ... */ });
const { finalContract } = await loadCompiledContract();
const { findDeployedContract, createCircuitCallTxInterface } =
  await import('@midnight-ntwrk/midnight-js-contracts');

await findDeployedContract(providers, {
  contractAddress,
  compiledContract: finalContract,
  privateStateId: PRIVATE_STATE_ID,
  initialPrivateState: createFundPrivateState(managerSk),
});

const txInterface = createCircuitCallTxInterface(
  providers, finalContract, contractAddress, PRIVATE_STATE_ID,
);

await txInterface.admitLp(hexToUint8Array(holderCommit), BigInt(allocation));

The lazy import of @midnight-ntwrk/midnight-js-contracts is significant — it's a ~1MB chunk and we don't need it until the user hits "Submit." Lazy-loading shaves the initial page-load by a few hundred ms.

Reading aggregate state

The Home page pulls the live AUM, ROI, LP count, and payout count straight from the indexer:

const provider = indexerPublicDataProvider(INDEXER_HTTP, INDEXER_WS);
const state = await provider.queryContractState(contractAddress);
const contractModule = await import('/src/contracts/managed/fund/contract/index.js');
const ledger = contractModule.ledger(state.data);

// ledger.totalLps         → bigint
// ledger.aum              → bigint
// ledger.reportedRoiBp    → bigint
// ledger.totalPayouts     → bigint

For a production fund-admin dashboard you'd want an Express + Postgres polling cache in front of the indexer. The pattern is documented in the upstream fullstack-dapp tutorial. For an MVP, querying the indexer directly on page load is fine.

What an auditor sees

A regulator or LP auditor with the contract address gets:

manager = 0x... (sealed GP key)
totalLps = 14
totalPayouts = 13
aum = 67_250_000
reportedRoiBp = 1200 (i.e. +12.00%)

From these they can verify:

Every payout consumed exactly the declared amount from AUM
No nullifier was reused
Every claim came from a commitment in the tree
The number of LPs match the number of admitLp transactions in the indexer history

What they cannot see:

Which wallet owns which commitment
Per-LP allocation amounts (those exist only in the GP's books)
The fund's strategy or holdings
Any cross-period linkage of an individual LP's claims (different period → different nullifier hash)

This is the trade-off the dApp embodies in one paragraph. The chain proves process integrity and solvency; identities and strategies stay off the chain entirely.

Production extensions worth building

Per-LP allocation commitments. Replace the disclosed allocation with a Pedersen commitment, and have the AUM accumulate commitments rather than scalars. More private, much more expensive in ZK proving time.
Time-locked GP transfer. Two-step proposeNewManager + acceptManager with a block_height + 100 delay. Catches the "GP key compromised" case.
Performance fees with high-water mark. Have the GP commit to a high-water mark, and reject performance-fee claims if the current period's ROI doesn't exceed it. Useful for hedge-fund style 2-and-20 fee structures.
Multi-fund routing. Replace manager: Bytes<32> with Map<Bytes<32>, Bytes<32>> keyed by fundId. One deployed contract hosts many funds, each with its own manager.
Real settlement. Pair with a shielded token so payouts mint actual coin commitments to fresh recipient addresses, instead of just decrementing a counter.

Troubleshooting

Vite throws "Failed to resolve import .../fund/contract/index.js" — you haven't compiled. Run npx compact compile contracts/Contract.compact src/contracts/managed/fund. The path matters: the frontend imports from exactly there.
Not the fund manager on admitLp / reportRoi — your wallet is not the one that deployed. Switch wallets or redeploy.
Not an LP of this fund on claimPayout — the GP hasn't called admitLp for your commitment yet, or you computed the commitment with a different fundId. Double-check the fundId you're claiming on matches exactly what was used at admit time.
Payout already claimed for this period — the nullifier is working. Move to the next period or wait for the GP to declare a new one.
Payout exceeds AUM — either the LP is claiming more than the fund can pay, or the GP hasn't admitted enough capital to cover this period's payouts. Recheck the math.
Proof generation hangs — your local proof server died. Restart with docker run -p 6300:6300 midnightntwrk/proof-server:8.0.3 midnight-proof-server -v. First proofs after a server restart can take 30–60 seconds.
Wallet not detected — Lace and 1AM inject window.midnight asynchronously. The ConnectButton polls for up to 3 seconds. If still nothing, the button deep-links to lace.io.
BalanceCheckOverspend (error 138) — you're out of tDUST. Hit the Preprod faucet.

Repo and next steps

Code: https://github.com/ayushsingh82/Midnight-dApps/tree/main/confidential-asset-management
Compact language reference: https://docs.midnight.network/

If you fork it and ship something interesting, I'd love to hear about it.

# [Tutorial] Confidential Dividend Distribution on Midnight

ayush singh — Wed, 13 May 2026 10:12:51 +0000

📁 Source: Midnight-dApps/confidential-dividend

A public corporate cap table is the unsolved scandal of on-chain finance. Every public company in the world reports aggregate shareholdings in 10-Q filings, but anyone who issues equity on a transparent blockchain effectively publishes positions of every holder, every insider, every family office — addressable by wallet ID forever. Half of corporate America walks away the moment you mention "on-chain."

Midnight gives you a way out. This dApp shows it.

A corporate issuer registers shareholders, tops up a dividend pool each quarter, and declares the per-share rate. Holders prove eligibility and claim with zero-knowledge proofs. Nullifiers enforce one-claim-per-cycle. Auditors and regulators see the totals; nobody sees the cap table.

The contract is ~120 lines of Compact. The frontend is one role-aware React app with three roles wired in (issuer, shareholder, observer). The whole thing runs on Midnight Preprod with the proof server hosted locally.

Three real use cases this unlocks

Late-stage private equity — companies that want to start paying preferred-stock dividends on-chain without revealing their cap table to competitors, journalists, or the SEC EDGAR scrapers. The holders are already known to the company (registered through onboarding), so the only privacy boundary that matters is the public one.
Tokenised co-ops and DAOs that act like co-ops — a member-owned org that distributes annual surplus to members. You want every member to be able to verify they were paid, and the public to be able to verify the org distributed exactly what it said it would, without doxxing every member.
Token-buyback and revenue-share programmes — a protocol that programmatically distributes a share of revenue to token holders, but doesn't want the holder list public (because price-sensitive insiders are on it). Today these programmes are either centralised escrow or fully public; Midnight enables a third option.

Prerequisites

Node 20+
Lace or 1AM, on Midnight Preprod
tNIGHT + tDUST from the Preprod faucet
Docker
Compact compiler:

curl --proto '=https' --tlsv1.2 -LsSf \
  https://github.com/midnightntwrk/compact/releases/latest/download/compact-installer.sh | sh

The contract walk-through

Full source: contracts/Contract.compact. I'll walk through it function by function.

Ledger state

pragma language_version 0.22;
import CompactStandardLibrary;

export sealed ledger issuer: Bytes<32>;

export ledger shareholderCommitments: HistoricMerkleTree<10, Bytes<32>>;
export ledger dividendNullifiers: Set<Bytes<32>>;

export ledger dividendPool: Uint<64>;
export ledger declaredDividend: Uint<64>;

export ledger totalShareholders: Counter;
export ledger totalDividendsPaid: Counter;

Five pieces of state worth knowing:

issuer is sealed. That means the value can only be written once, by the constructor. Every privileged circuit checks assert(issuer == publicKey(callerSk)). There's no admin transfer, by design — for an MVP this is fine; in production you'd add a multi-step transferIssuer flow.
shareholderCommitments is a depth-10 historic Merkle tree. "Historic" means proofs against older roots stay valid. So a shareholder who got registered 200 blocks ago can still prove they're a holder today.
dividendNullifiers is the anti-double-claim set. A nullifier is H(shareholderSk, classId, cycle). Two claims with the same triple produce the same nullifier; the second one gets rejected.
dividendPool is a public scalar. Anyone observing the contract knows exactly how much treasury is available.
declaredDividend is the per-share rate for the current cycle. Issuers update this each quarter via declareCycleDividend.

I deliberately kept it to a single share class. Adding multi-class support is straight-forward — you'd replace the Merkle tree and counters with a Map<Bytes<32>, ...> keyed by classId.

Witnesses

witness localSecretKey(): Bytes<32>;
witness findShareholderPath(commit: Bytes<32>): MerkleTreePath<10, Bytes<32>>;

Two witnesses. localSecretKey() fetches the caller's private key from off-chain state. findShareholderPath() finds the Merkle path from the caller's commitment to a root the tree has historically had.

The TypeScript side that resolves these:

export const witnesses = {
  localSecretKey: ({ privateState }) => [privateState, privateState.secretKey],
  findShareholderPath: ({ privateState, ledger }, commit) => {
    const path = ledger.shareholderCommitments.findPathForLeaf(commit);
    if (!path) throw new Error('Shareholder commitment not found in tree');
    return [privateState, path];
  },
};

The Midnight runtime hands these to Compact during proof generation. The path goes into the ZK proof; the chain only ever sees the resulting root assertion.

Constructor

constructor(issuerSk: Bytes<32>) {
    issuer = disclose(publicKey(issuerSk));
}

circuit publicKey(sk: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<2, Bytes<32>>>(
        [pad(32, "dividend:pk:v1"), sk]
    );
}

The deployer's secret key is passed in as a witness argument. We compute its public key (domain-separated with "dividend:pk:v1" so it doesn't collide with public keys in other dApps) and seal it. Nothing else is needed at deploy time.

`getShareholderCommitment(sk, classId)` — off-chain helper

circuit shareholderCommit(sk: Bytes<32>, classId: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<3, Bytes<32>>>(
        [pad(32, "dividend:sh:v1"), classId, sk]
    );
}

export circuit getShareholderCommitment(sk: Bytes<32>, classId: Bytes<32>): Bytes<32> {
    return shareholderCommit(sk, classId);
}

shareholderCommit is what makes the privacy model work. A shareholder's commitment is H(domain, classId, sk). Three properties matter:

Deterministic. Same wallet + same class → same commitment forever.
One-way. Even if the issuer leaks the entire tree, you can't reverse a commitment back to a wallet.
Domain-separated. The "dividend:sh:v1" padding ensures the same secret in a different dApp produces a different commitment.

getShareholderCommitment is the export wrapper, callable from the frontend as a pure circuit (no on-chain tx, just hash computation in JS).

`registerShareholder(commit)` — issuer only

export circuit registerShareholder(shareholderCommitArg: Bytes<32>): [] {
    const sk = localSecretKey();
    assert(issuer == disclose(publicKey(sk)), "Not the issuer");
    shareholderCommitments.insert(disclose(shareholderCommitArg));
    totalShareholders.increment(1);
}

The shareholder hands the issuer a commitment off-chain (Slack DM, KYC portal, anywhere). The issuer calls registerShareholder with it. The chain's only new fact: a leaf was added to the tree. The chain still doesn't know whose.

The disclose(publicKey(sk)) call is interesting — it computes the public key inside the circuit and crosses the public-private boundary. Without disclose, the compiler rejects the equality check.

`topUpDividendPool(amount)` — issuer only

export circuit topUpDividendPool(amount: Uint<64>): [] {
    const sk = localSecretKey();
    assert(issuer == disclose(publicKey(sk)), "Not the issuer");
    dividendPool = (dividendPool + amount) as Uint<64>;
}

Bumps the public pool counter. The as Uint<64> cast is needed because Compact requires explicit width annotations on arithmetic that might overflow.

In a real system you'd probably swap this for a circuit that accepts a shielded coin commitment and deposits actual tNIGHT into the contract. The accountant simplification here is for clarity.

`declareCycleDividend(amount)` — issuer only

export circuit declareCycleDividend(amount: Uint<64>): [] {
    const sk = localSecretKey();
    assert(issuer == disclose(publicKey(sk)), "Not the issuer");
    declaredDividend = amount;
}

Sets the per-share dividend for the upcoming cycle. Public. Every shareholder watching the contract knows what they can claim next.

There's no cycle argument here intentionally — the cycle is derived implicitly from the nullifier on the claim side. If you want a richer model you can declare per-cycle by adding a Map<Bytes<32>, Uint<64>>.

`claimDividend(classId, cycle)` — shareholder

export circuit claimDividend(classId: Bytes<32>, cycle: Bytes<32>): Boolean {
    const sk = localSecretKey();
    const commit = shareholderCommit(sk, classId);
    const path = findShareholderPath(commit);

    assert(
        shareholderCommitments.checkRoot(disclose(merkleTreePathRoot<10, Bytes<32>>(path))),
        "Not a registered shareholder"
    );

    const nul = dividendNullifier(sk, classId, cycle);
    assert(!dividendNullifiers.member(disclose(nul)), "Dividend already claimed this cycle");
    assert(dividendPool >= declaredDividend, "Insufficient dividend pool");

    dividendNullifiers.insert(disclose(nul));
    dividendPool = (dividendPool - declaredDividend) as Uint<64>;
    totalDividendsPaid.increment(1);

    return disclose(true);
}

This is the heart of the dApp. Four assertions in sequence:

The shareholder's commitment is in the Merkle tree. (checkRoot on a historic root.)
The nullifier for (sk, classId, cycle) hasn't been seen. This is what blocks the same shareholder from claiming twice in the same cycle.
The pool can cover the declared per-share amount.

If all three pass, we insert the nullifier, decrement the pool by the declared amount, and bump the public payout counter.

Notice the cycle is opaque bytes — the contract doesn't care if it's "2026-Q2", an ISO date, or a UNIX timestamp. The issuer just needs to keep using fresh values. Reusing a cycle ID is allowed, but it means each shareholder can only claim once across the cycle's lifetime.

Why does the chain learn the amount but not the recipient? Because we deduct from a public pool — the deduction has to be public for solvency. The recipient stays private because the proof verifies "some commitment in the tree" not "this particular commitment."

`proveEligibility(classId)` — shareholder, no-claim variant

export circuit proveEligibility(classId: Bytes<32>): Boolean {
    const sk = localSecretKey();
    const commit = shareholderCommit(sk, classId);
    const path = findShareholderPath(commit);
    assert(
        shareholderCommitments.checkRoot(disclose(merkleTreePathRoot<10, Bytes<32>>(path))),
        "Not a registered shareholder"
    );
    return disclose(true);
}

Same inclusion proof, but doesn't claim or touch the nullifier set. Useful for shareholder portals that want to gate features behind "are you a holder?" without burning a cycle.

You can build authentication flows on top of this — the dApp authenticates "yes, this caller is a holder of class X" without any password, OAuth, or off-chain database.

`dividendNullifier(sk, classId, cycle)` — private helper

circuit dividendNullifier(sk: Bytes<32>, classId: Bytes<32>, cycle: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<4, Bytes<32>>>(
        [pad(32, "dividend:nul:v1"), classId, cycle, sk]
    );
}

Four inputs into the hash: domain, classId, cycle, secret. Each new cycle changes the hash; each shareholder produces a different one. The result is the exact byte string the Set insertion checks against.

The frontend, by page

The router has four protected pages and one Home page:

<Routes>
  <Route path="/"         element={<HomePage />} />
  <Route path="/deploy"   element={<RequireWallet><DeployPage /></RequireWallet>} />
  <Route path="/register" element={<RequireWallet><RegisterPage /></RequireWallet>} />
  <Route path="/declare"  element={<RequireWallet><DeclarePage /></RequireWallet>} />
  <Route path="/claim"    element={<RequireWallet><ClaimPage /></RequireWallet>} />
</Routes>

RequireWallet redirects to / if isConnected is false on the Zustand store. Means you can't deep-link into Deploy without a wallet attached.

Wallet detection edge case

This one bit me. Lace and 1AM inject window.midnight after the React app mounts. If you read window.midnight once on mount, you'll miss late injections.

The fix is to poll for the first few seconds:

useEffect(() => {
  let attempts = 0;
  const id = window.setInterval(() => {
    const found = getCompatibleWallets();
    setWallets((prev) => (found.length !== prev.length ? found : prev));
    attempts += 1;
    if (attempts >= 10 || found.length > 0) window.clearInterval(id);
  }, 300);
  return () => window.clearInterval(id);
}, []);

Polls every 300ms for up to 3s. If a wallet shows up, we stop. If not, the "Install wallet" button shows up and deep-links to lace.io.

Deriving the role key

A single helper does the wallet → role key derivation:

const APP_SALT = 'confidential-dividend-v1';

export async function deriveRoleKey(shieldedCoinPublicKey, role) {
  const master = await deriveKeyFromPassword(APP_SALT, shieldedCoinPublicKey);
  return deriveKey(master, `dividend:${role}`);
}

Roles are 'shareholder' or 'issuer'. Same wallet = same role key forever, and an issuer using their issuer key can't accidentally act as a shareholder (different domain separator on the same wallet seed).

Submitting a circuit call

Every action page follows roughly the same pattern (Deploy/Register/Declare/Claim):

const providers = await buildProviders({
  connectedApi,
  shieldedCoinPublicKey: addresses.shieldedCoinPublicKey,
  shieldedEncryptionPublicKey: addresses.shieldedEncryptionPublicKey,
  privateStateStoreName: 'dividend',
});
const { finalContract } = await loadCompiledContract();
const { findDeployedContract, createCircuitCallTxInterface } =
  await import('@midnight-ntwrk/midnight-js-contracts');

await findDeployedContract(providers, {
  contractAddress,
  compiledContract: finalContract,
  privateStateId: PRIVATE_STATE_ID,
  initialPrivateState: createDividendPrivateState(issuerSk),
});

const txInterface = createCircuitCallTxInterface(
  providers, finalContract, contractAddress, PRIVATE_STATE_ID,
);
await txInterface.registerShareholder(hexToUint8Array(holderCommit));

The lazy import of @midnight-ntwrk/midnight-js-contracts keeps the initial bundle small — the contracts library is heavy and not needed until a user actually submits a transaction.

buildProviders lives in src/lib/midnight.ts and wires up six things (private-state level DB, indexer provider, ZK config, proof server, wallet adapter, midnight adapter). Centralising it means the page files stay focused on the UI.

Reading aggregate state

The Home page reads stats from the indexer:

const provider = indexerPublicDataProvider(INDEXER_HTTP, INDEXER_WS);
const state = await provider.queryContractState(contractAddress);
const contractModule = await import('/src/contracts/managed/dividend/contract/index.js');
const ledger = contractModule.ledger(state.data);

// ledger.totalShareholders     → bigint
// ledger.totalDividendsPaid    → bigint
// ledger.dividendPool          → bigint
// ledger.declaredDividend      → bigint

indexerPublicDataProvider wraps an Apollo client around indexer.preprod.midnight.network/api/v4/graphql. Calling queryContractState gives you raw ContractState; passing it through contractModule.ledger() deserialises it into typed fields.

For a production dashboard you'd usually layer an Express + Postgres cache in front of the indexer (the pattern from the upstream fullstack-dapp tutorial). Otherwise every page load hits the indexer.

Auditor view

An auditor or regulator with the contract address can verify, in zero knowledge but with full confidence:

That every payout consumed exactly declaredDividend from the pool
That no nullifier appears twice
That every claim came from a commitment in the tree
The exact number of shareholders, total payouts, and pool balance

What they cannot see:

Which wallet maps to which commitment
Any individual shareholder's claim count over time
Any link between two different dividend cycles for the same shareholder (because the nullifier hash is different each cycle)

This is the trade-off in one paragraph. The chain proves process integrity; the cap table stays off-chain.

What I'd build on top

Three concrete extensions:

Multi-class — replace the single tree with Map<Bytes<32>, HistoricMerkleTree<10, Bytes<32>>> keyed by classId. Different rates per class, same nullifier scheme.
Real settlement — pair with a shielded token. On claimDividend, mint a coin commitment to a fresh recipient address.
Time-locked declarations — the issuer commits to a future dividend rate cryptographically before the record date, and reveals it on schedule. Useful for compliance frameworks that require advance notice.

Troubleshooting

Vite throws "Failed to resolve import .../dividend/contract/index.js" — compile the contract first. The right command is npx compact compile contracts/Contract.compact src/contracts/managed/dividend. The path matters — the frontend imports from exactly that location.
Not the issuer on topUpDividendPool — you're calling from a wallet that wasn't the deployer. Switch wallets or redeploy.
Not a registered shareholder on claimDividend — issuer hasn't called registerShareholder for your commitment yet. Verify the issuer's logs show the registration tx succeeded, and that you computed the commitment with the same classId you're now claiming on.
Dividend already claimed this cycle — pick a fresh cycle ID, or wait for the issuer to declare a new one.
Insufficient dividend pool — issuer needs to topUpDividendPool before the next batch of claims. The contract correctly rejects payouts that would overdraw.
WebSocket disconnects during proof generation — the proof server can take 30+ seconds for first-time circuit proving. Don't refresh the page. If it really dies, the wallet shows "Connection failed" and you can retry.
Transactions stuck "pending" — Midnight Preprod blocks are roughly every 6 seconds. If it's been more than 30 seconds, check explorer.1am.xyz for the tx hash. If it's not there, it never got submitted — usually means your wallet was out of tDUST.

Repo and next steps

Code: https://github.com/ayushsingh82/Midnight-dApps/tree/main/confidential-dividend
Compact language reference: https://docs.midnight.network/

If you fork it and ship something interesting, I'd love to hear about it.

# [Tutorial] Building Confidential Tokenized Real Estate on Midnight

ayush singh — Wed, 13 May 2026 10:11:10 +0000

📁 Source: Midnight-dApps/confidential-real-estate

I've been watching real-estate tokenisation projects come and go for years. Every one of them has the same blocker: cap-table privacy. The minute you put a property's ownership on a transparent ledger, you're publishing who owns what to the entire world. Family offices won't touch it. RIAs won't touch it. And the institutional money that this market needs to scale just isn't going to show up.

Midnight changes the math. The chain stores commitments instead of identities, ZK proofs replace public lookups, and suddenly the trade-off between regulatory auditability and shareholder privacy goes away.

This is a working dApp that demonstrates the pattern. I'll walk through the contract function by function, the React frontend that talks to it, the wallet integration, and the bits that took me longer than they should have.

What we're actually building

A property sponsor (think: a building owner or a REIT issuer) deploys a contract. They can issue fractional shares in a property by inserting an investor's commitment into a Merkle tree. The investor can then later prove ownership of that property in zero knowledge, and claim a slice of the rental pool each cycle.

The bits that are public:

Total number of properties registered
Total shares issued (count of leaves in the tree)
Rental pool size
Total yield claims processed

The bits that stay private:

Which wallet owns which property
Each holder's allocation size
The mapping between commitments and real-world identities

That mapping happens off-chain, between the investor and the sponsor. The sponsor does KYC, decides allocations, and only puts a hash into the tree. Everyone after that point sees only the tree.

Why this dApp could actually ship

Three concrete use cases I'd build on top of this:

Family-office REIT — a single private REIT that wants to onboard 40-50 family offices without leaking any of their positions to each other. Today this is done with paper certificates and an SS&C transfer agent. Move it to Midnight and you keep the privacy but settle in seconds.
Fractional luxury rentals — Airbnb-style rentals where the building is fractionally owned by users, and rental income flows back to holders pro-rata. Users want to invest without doxxing themselves as owners of a specific building.
Regulated tokenised mortgages — the lender is a public entity but the borrowers / co-investors want their participation hidden from competitors. Aggregate compliance numbers (total loaned, total outstanding) stay public; per-borrower amounts don't.

Prerequisites

Node 20+
Lace or 1AM wallet, on the Midnight Preprod network
Some tNIGHT and tDUST from the Preprod faucet
Docker (for the local proof server)
The Compact compiler — curl --proto '=https' --tlsv1.2 -LsSf https://github.com/midnightntwrk/compact/releases/latest/download/compact-installer.sh | sh

The contract, function by function

The whole contract is about 110 lines. Here's the full ledger declaration first:

pragma language_version 0.22;
import CompactStandardLibrary;

export sealed ledger sponsor: Bytes<32>;

export ledger ownershipCommitments: HistoricMerkleTree<10, Bytes<32>>;
export ledger yieldClaimNullifiers: Set<Bytes<32>>;

export ledger totalProperties: Counter;
export ledger totalShares: Counter;
export ledger totalYieldClaims: Counter;

export ledger rentalPoolAvailable: Uint<64>;

A few things worth pointing out before we move on:

sealed ledger for the sponsor means the value can only be set once, in the constructor. After that, no circuit can change it. This is how we enforce "only the sponsor can issue shares."
HistoricMerkleTree<10, Bytes<32>> is a tree of depth 10 (so up to 2¹⁰ = 1024 leaves) where each leaf is 32 bytes. The "historic" part is crucial: proofs against past roots stay valid, which means an investor whose commitment was added 50 blocks ago can still prove they're in the tree.
Set<Bytes<32>> for nullifiers gives us O(log n) double-claim prevention. Once a nullifier goes in, the contract rejects any future tx that tries to add the same one.
Counter and Uint<64> are public scalars. Anyone can read them off the indexer.

`constructor(sponsorSk: Bytes<32>)`

constructor(sponsorSk: Bytes<32>) {
    sponsor = disclose(publicKey(sponsorSk));
}

The constructor takes the sponsor's secret key (32 bytes, witness data — never appears on chain) and seals the corresponding public key into the contract. disclose(...) tells the compiler this value crosses the public-private boundary on purpose.

publicKey() is a private helper:

circuit publicKey(sk: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<2, Bytes<32>>>(
        [pad(32, "realestate:pk:v1"), sk]
    );
}

The pad(32, "realestate:pk:v1") is a 32-byte domain separator. Without it, the same secret key could collide with a public key in a different dApp using the same hash function. The :v1 suffix is there in case we ever want to migrate to a different hash without invalidating identities.

`getOwnershipCommitment(sk, propertyId)`

This is the only circuit the frontend calls off-chain. It's marked export and uses pureCircuits, which means it runs in JavaScript without producing a transaction:

circuit ownershipCommit(sk: Bytes<32>, propertyId: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<3, Bytes<32>>>(
        [pad(32, "realestate:own:v1"), propertyId, sk]
    );
}

export circuit getOwnershipCommitment(sk: Bytes<32>, propertyId: Bytes<32>): Bytes<32> {
    return ownershipCommit(sk, propertyId);
}

This is what produces the 64-character hex string the investor copies on the Home page. It's deterministic: the same wallet + same property always gives the same commitment. That's what makes "lose your password, lose your identity" actually work — there's no extra randomness needed, the wallet is sufficient.

`issueShare(holderCommit)` — sponsor-only

export circuit issueShare(holderCommit: Bytes<32>): [] {
    const sk = localSecretKey();
    assert(sponsor == disclose(publicKey(sk)), "Not the sponsor");
    ownershipCommitments.insert(disclose(holderCommit));
    totalShares.increment(1);
}

Three things happening here:

The witness localSecretKey() pulls the caller's secret key out of their private state. (We'll see how this is wired up shortly.)
The assertion sponsor == publicKey(sk) is what gates this circuit to the sponsor only. If any other wallet tries to call issueShare, their publicKey(sk) won't match the sealed sponsor and the proof generation fails before a transaction is ever submitted.
The commitment goes into the tree. The chain learns that a new leaf was added — nothing about who.

totalShares.increment(1) is a public counter and useful for dashboards. You could also have the sponsor pass an explicit share count and increment by that amount, but I kept it simple.

`registerProperty()` — sponsor-only

export circuit registerProperty(): [] {
    const sk = localSecretKey();
    assert(sponsor == disclose(publicKey(sk)), "Not the sponsor");
    totalProperties.increment(1);
}

This is a bookkeeping circuit that just bumps a counter. You'd call it once per property the sponsor onboards, so the public dashboard can show "12 properties registered." It doesn't change anything else.

`depositRent(amount)` — sponsor-only

export circuit depositRent(amount: Uint<64>): [] {
    const sk = localSecretKey();
    assert(sponsor == disclose(publicKey(sk)), "Not the sponsor");
    rentalPoolAvailable = (rentalPoolAvailable + amount) as Uint<64>;
}

Adds to the rental pool. Public on-chain because everyone watching the tree wants to know how much money is available for yield claims this cycle.

In a real system the sponsor wouldn't just add to a counter — they'd send actual tokens to the contract. You can pair this with a shielded token and have depositRent accept a coin commitment.

`proveOwnership(propertyId)` — investor

export circuit proveOwnership(propertyId: Bytes<32>): Boolean {
    const sk = localSecretKey();
    const commit = ownershipCommit(sk, propertyId);
    const path = findOwnershipPath(commit);

    assert(
        ownershipCommitments.checkRoot(disclose(merkleTreePathRoot<10, Bytes<32>>(path))),
        "Not an owner of this property"
    );

    return disclose(true);
}

This is where the ZK magic happens. The investor:

Fetches their own secret key via localSecretKey() (witness).
Recomputes their commitment locally — ownershipCommit(sk, propertyId).
Asks the witness findOwnershipPath(commit) to provide the Merkle path from that commitment to a root the tree has seen.
Asserts the path roots match. If they do, the proof succeeds.

The on-chain effect of a successful call: nothing. No state changes. The wallet just records that the tx was submitted. But the chain has now mathematically certified that somebody who owns property X has proven ownership — without revealing who.

This is useful for "did you own this property at any point" verifications. A KYC portal, a tenant directory, a benefits programme — anything that needs proof of ownership without leaking identity.

`claimYield(propertyId, cycle, amount)` — investor

export circuit claimYield(propertyId: Bytes<32>, cycle: Bytes<32>, amount: Uint<64>): Boolean {
    const sk = localSecretKey();
    const commit = ownershipCommit(sk, propertyId);
    const path = findOwnershipPath(commit);

    assert(
        ownershipCommitments.checkRoot(disclose(merkleTreePathRoot<10, Bytes<32>>(path))),
        "Not an owner of this property"
    );

    const nul = yieldNullifier(sk, propertyId, cycle);
    assert(!yieldClaimNullifiers.member(disclose(nul)), "Yield already claimed this cycle");
    assert(rentalPoolAvailable >= amount, "Insufficient rental pool");

    yieldClaimNullifiers.insert(disclose(nul));
    rentalPoolAvailable = (rentalPoolAvailable - amount) as Uint<64>;
    totalYieldClaims.increment(1);

    return disclose(true);
}

Same ownership check as proveOwnership, plus three more assertions:

The nullifier H(sk, propertyId, cycle) hasn't been seen before. If it has, this investor already claimed for this cycle.
The rental pool has enough funds for this payout.
We insert the nullifier and decrement the pool.

The cycle argument is what makes this work over time. Every quarter the sponsor sets a new cycle ID ("2026-Q2", "2026-Q3"), and each (investor, property, cycle) tuple produces a fresh nullifier. Without the cycle in the nullifier hash, the investor could only ever claim once and never again.

You'll notice amount is public — it has to be, so the pool can be decremented correctly. The privacy isn't in the amount, it's in who's claiming. If you want amounts to be private too, you'd shield the rental pool itself and pay out from there.

The witnesses

Witnesses are the link between the on-chain circuit and the off-chain private state. Two of them:

// confidential-real-estate/src/pages/witnesses.ts
export const witnesses = {
  localSecretKey: ({ privateState }) => [privateState, privateState.secretKey],
  findOwnershipPath: ({ privateState, ledger }, commit) => {
    const path = ledger.ownershipCommitments.findPathForLeaf(commit);
    if (!path) throw new Error('Ownership commitment not found in tree');
    return [privateState, path];
  },
};

localSecretKey just hands the circuit the secret key from the local private state — never touches the chain.

findOwnershipPath is a bit cleverer. It looks at the local copy of the ledger that the Midnight.js client has been syncing in the background, walks the Merkle tree, and finds the path from the requested commitment to the root. That path is what proveOwnership and claimYield verify on-chain.

If the commitment isn't in the local tree yet — for example, the sponsor only just added it and our client hasn't caught up — findPathForLeaf returns null and we throw. The wallet displays the error to the user.

The deterministic identity

Every action on the dApp is signed with a key derived from your wallet:

// confidential-real-estate/src/hooks/useIdentity.ts
const APP_SALT = 'confidential-real-estate-v1';

export async function deriveRoleKey(shieldedCoinPublicKey, role) {
  const master = await deriveKeyFromPassword(APP_SALT, shieldedCoinPublicKey);
  return deriveKey(master, `realestate:${role}`);
}

deriveKeyFromPassword is PBKDF2 with 100,000 iterations of SHA-256. The "password" here is a static salt; the per-user entropy comes from shieldedCoinPublicKey, which is fully determined by the wallet's seed phrase. Same wallet → same key, always.

Earlier versions of this dApp had a separate user password on top of this. I dropped it because it was just adding a UX step without meaningful security gain — if someone has your wallet seed, they already control your assets; an extra password doesn't help. (If you want belt-and-braces security, add a passphrase wallet-side, not dApp-side.)

Wiring up the providers

The frontend talks to Midnight through a bundle of providers, one for each concern:

// shape (real wiring is in src/pages/Deploy.tsx)
const providers = {
  privateStateProvider: levelPrivateStateProvider({ privateStateStoreName: 'realestate' }),
  publicDataProvider:   indexerPublicDataProvider(INDEXER_HTTP, INDEXER_WS),
  zkConfigProvider:     new FetchZkConfigProvider(`${CONTRACT_PATH}/managed/realestate/keys`, fetch.bind(window)),
  proofProvider:        httpClientProofProvider(PROOF_SERVER, zkConfig),
  walletProvider:       { ...balanceTx + getCoinPublicKey adapters... },
  midnightProvider:     { ...submitTx adapter... },
};

In English:

privateStateProvider is the local IndexedDB store for your secret key + cached tree state. Clearing browser storage clears this — but since the key is deterministic, it gets rederived on next page load.
publicDataProvider reads chain state from the GraphQL indexer at indexer.preprod.midnight.network.
zkConfigProvider loads the proving/verifier keys generated by compact compile. Heavy artefacts (~megabytes each).
proofProvider is your local proof server at localhost:6300. Heavy CPU work happens here.
walletProvider adapts the Midnight JS transaction format to whatever your wallet extension expects.
midnightProvider does the final submit.

Deploying the contract

const { finalContract } = await loadCompiledContract();
const result = await deployContract(providers, {
  compiledContract: finalContract,
  privateStateId: PRIVATE_STATE_ID,
  initialPrivateState: createRealEstatePrivateState(sponsorSk),
  args: [sponsorSk],
});
const contractAddress = result.deployTxData.public.contractAddress;

args: [sponsorSk] is what gets passed to the Compact constructor. The sponsor public key gets sealed in, and now only this wallet (or anyone who knows their seed) can ever call issueShare or depositRent.

The contract address is a 64-char hex string. We stash it in localStorage so the rest of the app knows which contract to talk to.

Submitting a circuit call

After the contract is deployed, every circuit call follows the same shape:

const txInterface = createCircuitCallTxInterface(
  providers, finalContract, contractAddress, PRIVATE_STATE_ID
);
await txInterface.issueShare(hexToUint8Array(holderCommit));

Internally that does roughly:

Look up the circuit by name on the compiled contract.
Resolve witnesses against your private state.
Build an unsigned transaction including the ZK proof.
Hand it to the wallet provider to balance and sign.
Submit through the midnight provider.

If anything fails — invalid commitment, mismatched root, proof timeout — the wallet popup shows the error and the chain state stays clean.

The Home dashboard

The investor's Home page shows a property gallery (London / NYC / Singapore mock listings), the live commitment for whichever property is selected, the contract address, and a quick-action grid.

// src/pages/Home.tsx (simplified)
const investorSk = useIdentity('investor');
useEffect(() => {
  if (!investorSk) return;
  const data = new Uint8Array(64);
  data.set(investorSk);
  data.set(padTo32Bytes(propertyId), 32);
  const hash = await crypto.subtle.digest('SHA-256', data);
  setCommitHex(uint8ArrayToHex(new Uint8Array(hash)));
}, [investorSk, propertyId]);

This is a SHA-256 sketch of the commitment — it's not bit-for-bit identical to what getOwnershipCommitment produces on-chain (which uses Midnight's persistentHash), but it's good enough to give the user a stable hex string to share off-band. In production you'd want to either:

Call the pureCircuit on-chain helper, which gives you the exact hash, or
Reimplement the Midnight persistentHash in JS and use it directly.

The current dApp uses SHA-256 as a placeholder because the pureCircuit import is heavy and only available after compile. A real production version would do the swap.

What's not in the dApp (yet)

I deliberately left these out to keep the demo focused:

Per-share weighting. Currently each commitment is "one share." For variable allocations you'd store a Map<Bytes<32>, Uint<64>> mapping commitment to share count, then weight yield claims by it.
Property NFTs. No on-chain link between a property and any external identifier. You'd add a Map<Bytes<32>, Bytes<32>> mapping propertyId to a property-metadata hash.
Redemption / share burn. Once issued, shares stay in the tree forever. Adding a redemption nullifier set per (investor, property) gives you partial exits.
Real token settlement. The rental pool is a Uint<64> accumulator, not a real shielded token balance. Plug in a shielded token for real money movement.

Any of these would make a fun PR.

Troubleshooting from live testing

Failed to resolve import "/src/contracts/managed/realestate/contract/index.js" — you haven't compiled the contract yet. Run npx compact compile contracts/Contract.compact src/contracts/managed/realestate. The frontend imports the contract at that exact path.
Wallet not detected — Lace and 1AM inject window.midnight asynchronously. The ConnectButton polls for a couple of seconds after mount to pick that up. If it's still not found, the button deep-links to lace.io.
Not the sponsor on issueShare — your wallet doesn't match the wallet that deployed. Switch to the deployer wallet or redeploy.
Not an owner of this property on claimYield — sponsor hasn't called issueShare for your commitment yet, or you computed the commitment with a different propertyId than the one you're claiming on. Double-check the spelling.
Yield already claimed this cycle — the nullifier is doing its job. Pick a different cycle ID or wait for the sponsor to declare the next one.
Tx hangs at "Generating proof" — your local proof server probably died. Re-run docker run -p 6300:6300 midnightntwrk/proof-server:8.0.3 midnight-proof-server -v.
BalanceCheckOverspend (error 138) — your wallet doesn't have enough tDUST to pay tx fees. Hit the Preprod faucet.

Where to go next

Clone the repo and try it: https://github.com/ayushsingh82/Midnight-dApps
Extend the contract with per-share weighting (the most-requested feature).
Read the Midnight Compact docs for the full circuit/witness/ledger model.

If you fork it and ship something interesting, I'd love to hear about it.

Forem: ayush singh

# [Tutorial] Confidential Asset Management on Midnight

Use cases this could actually serve

Prerequisites

Privacy/auditability — where the line sits

The contract

Ledger state

Witnesses

Constructor

getLpCommitment(sk, fundId) — off-chain helper

admitLp(commit, allocation) — GP only

reportRoi(roiBp) — GP only

redeemLp(commit, allocation) — GP only

proveLp(fundId) — LP, no-claim variant

claimPayout(fundId, period, amount) — LP

payoutNullifier(sk, fundId, period) — private helper

Frontend wiring

Wallet → role key

The provider bundle

Submitting a circuit call

Reading aggregate state

What an auditor sees

Production extensions worth building

Troubleshooting

Repo and next steps

# [Tutorial] Confidential Dividend Distribution on Midnight

Three real use cases this unlocks

Prerequisites

The contract walk-through

Ledger state

Witnesses

Constructor

getShareholderCommitment(sk, classId) — off-chain helper

registerShareholder(commit) — issuer only

topUpDividendPool(amount) — issuer only

declareCycleDividend(amount) — issuer only

claimDividend(classId, cycle) — shareholder

proveEligibility(classId) — shareholder, no-claim variant

dividendNullifier(sk, classId, cycle) — private helper

The frontend, by page

Wallet detection edge case

Deriving the role key

Submitting a circuit call

Reading aggregate state

Auditor view

What I'd build on top

Troubleshooting

Repo and next steps

# [Tutorial] Building Confidential Tokenized Real Estate on Midnight

What we're actually building

Why this dApp could actually ship

Prerequisites

The contract, function by function

constructor(sponsorSk: Bytes<32>)

getOwnershipCommitment(sk, propertyId)

issueShare(holderCommit) — sponsor-only

registerProperty() — sponsor-only

depositRent(amount) — sponsor-only

proveOwnership(propertyId) — investor

claimYield(propertyId, cycle, amount) — investor

The witnesses

The deterministic identity

Wiring up the providers

Deploying the contract

Submitting a circuit call

The Home dashboard

What's not in the dApp (yet)

Troubleshooting from live testing

Where to go next

`getLpCommitment(sk, fundId)` — off-chain helper

`admitLp(commit, allocation)` — GP only

`reportRoi(roiBp)` — GP only

`redeemLp(commit, allocation)` — GP only

`proveLp(fundId)` — LP, no-claim variant

`claimPayout(fundId, period, amount)` — LP

`payoutNullifier(sk, fundId, period)` — private helper

`getShareholderCommitment(sk, classId)` — off-chain helper

`registerShareholder(commit)` — issuer only

`topUpDividendPool(amount)` — issuer only

`declareCycleDividend(amount)` — issuer only

`claimDividend(classId, cycle)` — shareholder

`proveEligibility(classId)` — shareholder, no-claim variant

`dividendNullifier(sk, classId, cycle)` — private helper

`constructor(sponsorSk: Bytes<32>)`

`getOwnershipCommitment(sk, propertyId)`

`issueShare(holderCommit)` — sponsor-only

`registerProperty()` — sponsor-only

`depositRent(amount)` — sponsor-only

`proveOwnership(propertyId)` — investor

`claimYield(propertyId, cycle, amount)` — investor