DEV Community: Arihant Agarwal

Security Checklist for Midnight dApps Before Deployment

Arihant Agarwal — Sun, 10 May 2026 23:30:59 +0000

Midnight gives DApp developers a different security model from public-by-default chains. A Midnight smart contract can keep sensitive data local, prove facts about that data with ZK proofs, and write only selected outputs to public ledger state. That power creates a clear deployment responsibility: every public write, every witness value, every authorization check, and every proof-generation path must be reviewed before launch.

Use this tutorial as a durable pre-deployment checklist. It is written for developers who already have a Compact smart contract and want a repeatable audit process before deploying to Preview, Preprod, or Mainnet.

This guide is for Midnight DApp developers who write Compact smart contracts, implement TypeScript witnesses, and configure Midnight.js or related tooling for proof generation and transaction submission.

Prerequisites

Before you begin, make sure you have:

Node.js 22 or later.
Docker Desktop or another Docker-compatible runtime.
The Compact devtools installed.
A compiled Midnight smart contract in a project with TypeScript tests.
Access to a local proof server or the correct Preview, Preprod, or Mainnet proof server endpoint.
Lace configured for the target environment when wallet interaction is part of your test flow.

Required reading

Review these pages before running the checklist:

Start with a clean verification gate

Run the same gate before every security review and keep it in CI.

compact --version
compact compile --version
compact compile --language-version
compact compile --runtime-version
compact compile --ledger-version
compact format --check src/
compact fixup --check src/
npm run compact
npm run typecheck
npm test

For the official bulletin board example, the Compact script compiles the source smart contract into generated TypeScript, JavaScript, ZKIR, proving keys, verifier keys, and compiler metadata:

{
  "scripts": {
    "compact": "compact compile src/bboard.compact ./src/managed/bboard",
    "ci": "npm run compact && npm run typecheck && npm run lint && npm run build && npm run test"
  }
}

Do not review stale generated files. Delete generated output, recompile, run tests, and review generated metadata from the deployment commit.

Understand the security boundary

A Compact smart contract spans three contexts:

Public ledger state: On-chain state that observers, indexers, and DApps can read.
ZK circuits: Compact logic that proves valid execution without revealing private inputs.
Local witnesses: TypeScript or JavaScript callbacks that run on the user's machine and supply private values.

Most Midnight bugs appear at the boundary between those contexts. The compiler helps prevent accidental disclosure, but it cannot decide whether a disclosure is safe for your logic or make a witness implementation trustworthy.

1. Audit every `disclose()` call

The disclose() wrapper is an explicit statement that a value derived from witness data, exported circuit arguments, or constructor arguments is safe to place in a public context. Public contexts include public ledger assignments, values returned from exported circuits, and values passed to another smart contract.

Start with a simple inventory:

grep -R "disclose(" -n src contract contracts

For each result, write down:

The exact value being disclosed.
The private inputs or witness values that can influence it.
The public destination, such as export ledger owner, an exported circuit return value, or a cross-smart-contract argument.
The reason that disclosure is necessary.
The privacy impact if a user links this value across transactions.

A safe disclose() sits close to the public write. Avoid disclosing a private value early and passing it through multiple branches. That makes later review harder.

The bulletin board ownership pattern shows a narrow disclosure. The smart contract does not disclose the local secret key. It discloses a hash commitment derived from a domain separator, the current sequence number, and the local secret key.

pragma language_version >= 0.22;

import CompactStandardLibrary;

export enum State {
  VACANT,
  OCCUPIED
}

export ledger state: State;
export ledger message: Maybe<Opaque<"string">>;
export ledger sequence: Counter;
export ledger owner: Bytes<32>;

constructor() {
  state = State.VACANT;
  message = none<Opaque<"string">>();
  sequence.increment(1);
}

witness localSecretKey(): Bytes<32>;

export circuit post(newMessage: Opaque<"string">): [] {
  assert(state == State.VACANT, "Attempted to post to an occupied board");
  owner = disclose(publicKey(localSecretKey(), sequence as Field as Bytes<32>));
  message = disclose(some<Opaque<"string">>(newMessage));
  state = State.OCCUPIED;
}

export circuit takeDown(): Opaque<"string"> {
  assert(state == State.OCCUPIED, "Attempted to take down post from an empty board");
  assert(owner == publicKey(localSecretKey(), sequence as Field as Bytes<32>), "Attempted to take down post, but not the current owner");
  const formerMsg = message.value;
  state = State.VACANT;
  sequence.increment(1);
  message = none<Opaque<"string">>();
  return formerMsg;
}

export circuit publicKey(sk: Bytes<32>, sequence: Bytes<32>): Bytes<32> {
  return persistentHash<Vector<3, Bytes<32>>>([pad(32, "bboard:pk:"), sequence, sk]);
}

Review owner and message differently. owner is safe only because it is a one-way, domain-separated commitment. message is intentionally public. The compiler enforces explicitness. You enforce policy.

Pass this section only when every disclosure has a documented purpose and a negative privacy test.

2. Review `ownPublicKey()` usage

Search for ownPublicKey() before any deployment:

grep -R "ownPublicKey" -n src contract contracts

A match in authorization code is a release blocker. Midnight's security guidance treats ownPublicKey() as a witness function. A DApp frontend can provide witness results, so a circuit must not use ownPublicKey() as proof that the caller owns the matching secret key.

Prefer a witness-based commitment pattern:

Keep the secret key in local private state.
Return it through a witness such as localSecretKey().
Derive a DApp-specific commitment with persistentHash and a clear domain separator.
Store only the commitment in public ledger state.
Recompute the commitment inside protected circuits and assert equality against public state.
Include a sequence, round, or nonce when linkability matters.

In the bulletin board pattern, post() stores owner as a commitment. Later, takeDown() recomputes the same commitment with localSecretKey() and the current sequence. The caller proves knowledge of the private input that opens the commitment without revealing the secret key.

Your review should classify each authorization path:

Allowed: assert(publicKey(localSecretKey(), round) == owner, "Operation not permitted") when owner is a stored commitment for that round.
Allowed after another check: ownPublicKey() used for display, routing, or wallet-related logic after the caller has passed an independent proof.
Blocked: assert(ownPublicKey() == owner, "Only owner") or any equivalent caller-verification check.

Pass this section only when no exported circuit depends on ownPublicKey() for caller verification.

3. Verify replay protection with nonces or nullifiers

A valid proof can still be dangerous if it can be reused in the wrong context. Replay protection binds an action to a unique state, round, nonce, or resource.

Search for replay primitives and state-versioning fields:

grep -R "Counter\|nonce\|nullifier\|claimZswapNullifier\|sequence\|round" -n src contract contracts

Use a Counter, round, or explicit nonce for state-machine actions. The bulletin board example uses sequence for this. The current poster's commitment includes the current sequence. When the message is removed, sequence.increment(1) invalidates the old commitment for the next post. This prevents old ownership proofs from applying to a later board cycle.

Use nullifiers for one-time resources, shielded notes, private claims, coupons, votes, withdrawals, or any operation where a private resource must be consumed exactly once. The ledger kernel exposes claimZswapNullifier(nul: Bytes<32>) to require a nullifier in the containing transaction and prevent another call from claiming the same nullifier in that transaction.

Your replay review should answer these questions:

What makes this call unique?
Does the uniqueness value appear inside the commitment or nullifier derivation?
Does the smart contract update the uniqueness value after a successful call?
Can a stale proof apply after state changes?
Can two calls in the same transaction consume the same resource?

Add negative tests for replay attempts. A good test calls the same action twice with the same private input and the same public state snapshot, then expects the second call to fail or produce a different required state boundary. For nullifier flows, add a test that attempts to consume the same private resource twice and expects rejection.

Pass this section only when every state-changing circuit has an explicit anti-replay story and a negative test.

4. Review exported ledger fields

Anything declared with export ledger is part of the public interface. Treat exported ledger fields as API surface. They are useful for DApps, indexers, and tests, but they also reveal information.

Search all ledger declarations:

grep -R "export[[:space:]]\+ledger\|sealed[[:space:]]\+ledger\|^[[:space:]]*ledger" -n src contract contracts

For each ledger field, classify the field as:

Public by design: state enums, counters, public messages, public commitments, public configuration, and public totals.
Public but sensitive: hashes, commitments, status flags, timestamps, or counters that could link users or reveal behavior.
Not acceptable: raw secrets, raw private identifiers, raw credentials, hidden vote choices, private notes, unblinded amounts, or values that reconstruct private state.

Use sealed ledger for values that must be initialized once and stay immutable, such as domain separators, policy IDs, configured limits, or deployment parameters. A sealed field can be set during initialization, but exported circuits cannot modify it later.

Compact toolchain 0.31.0 adds public ledger state layout to contract-info.json. After compilation, inspect that generated file and compare it with your manual ledger inventory:

compact compile src/bboard.compact src/managed/bboard
cat src/managed/bboard/compiler/contract-info.json

Do not rely on source review alone. Generated metadata catches fields that appear through modules, imports, and generated layouts. Keep a ledger review file with this shape:

| Field | Exported | Sealed | Type | Public reason | Privacy risk | Approved by |
| --- | --- | --- | --- | --- | --- | --- |
| state | yes | no | State | DApp renders board status | Low | Security reviewer |
| message | yes | no | Maybe<Opaque<"string">> | Message is intentionally public | User content is public | Product owner |
| sequence | yes | no | Counter | Replay boundary | May reveal activity count | Security reviewer |
| owner | yes | no | Bytes<32> | Ownership commitment | Linkable within one sequence | Security reviewer |

Pass this section only when every exported field has a documented public reason.

5. Verify witness implementation correctness

Witness declarations in Compact have no body. The DApp implements them in TypeScript or JavaScript. That means witness logic belongs in the security review.

A witness implementation returns a tuple: the new private state and the value passed back into the circuit. The bulletin board witness returns the same private state and the user's local secret key:

import { Ledger } from "./managed/bboard/contract/index.js";
import { WitnessContext } from "@midnight-ntwrk/compact-runtime";

export type BBoardPrivateState = {
  readonly secretKey: Uint8Array;
};

export const createBBoardPrivateState = (secretKey: Uint8Array) => ({
  secretKey,
});

export const witnesses = {
  localSecretKey: ({
    privateState,
  }: WitnessContext<Ledger, BBoardPrivateState>): [
    BBoardPrivateState,
    Uint8Array,
  ] => [privateState, privateState.secretKey],
};

Review every witness for these requirements:

The return type matches the Compact declaration exactly.
Bytes<32> maps to a Uint8Array with length 32.
Uint values use bigint where generated types require it.
The witness does not read from remote services during proof generation unless that dependency is authenticated, stable, and tested.
The witness does not log secrets, notes, nullifiers, credentials, raw votes, or private amounts.
The witness updates private state deterministically when a later circuit call depends on that update.
The circuit validates the returned value before relying on it.

Treat witness values as untrusted inputs. If a witness returns a balance, membership flag, score, credential, or secret, the circuit must verify it through commitments, Merkle paths, signatures, nullifiers, public state, or another cryptographic check. Do not accept a witness result because your own frontend returns the expected value.

Add tests for malicious witness values. Replace a valid secret key with another 32-byte value and expect authorization to fail. Return an out-of-range amount and expect an assertion. Return a stale Merkle path and expect rejection.

Pass this section only when every witness has type tests, negative tests, and a circuit-level validation path.

6. Confirm version compatibility

Version mismatches create confusing failures. A proof can fail when generated files, runtime packages, ledger version, and proof server version do not match.

Use the compatibility matrix as the source of truth for the release you target. At the time of this tutorial, the latest tested stack lists Compact devtools 0.5.1, Compact toolchain 0.31.0, Compact runtime 0.16.0, Ledger 8.0.3, Midnight.js 4.0.4, testkit-js 4.0.4, and proof server 8.0.3.

Run these checks in CI:

compact list --installed
compact compile --version
compact compile --language-version
compact compile --runtime-version
compact compile --ledger-version
npm ls --depth=0 | grep '@midnight-ntwrk'

Pin versions in package.json. Do not mix Ledger 8 generated files with a Ledger 7 proof server or older Midnight.js packages. Recompile after every dependency update, even when TypeScript still passes.

Upgrade flow:

compact update 0.31
rm -rf node_modules package-lock.json
npm install
npm run compact
npm run typecheck
npm test

After upgrading, inspect generated files and contract-info.json again. Toolchain 0.31.0 includes public ledger layout in that file.

Pass this section only when versions match the target environment and generated files come from the pinned compiler.

7. Test proof generation on Testnet or a local network

Unit tests are necessary, but they do not replace proof generation. Before Mainnet deployment, run a full flow that generates ZK proofs, submits transactions, waits for finalization, and reads public state.

Start a local proof server with the version from the compatibility matrix:

docker run -p 6300:6300 midnightntwrk/proof-server:8.0.3 midnight-proof-server -v

The proof server listens on port 6300. Keep it running while deploying or interacting with your DApp. Use a local proof server or a controlled endpoint for sensitive test data.

For final pre-production testing, use Preprod. Preview is suitable for early development and experimentation. Preprod is designed for final testing before Mainnet deployment. Mainnet is the production network.

Your proof-generation test should cover:

Deploy the smart contract.
Submit a successful transaction for each exported state-changing circuit.
Wait for the transaction receipt and assert the applied status.
Query the public ledger state and confirm only approved fields changed.
Submit a negative transaction for each authorization and replay boundary.
Restart the DApp process and confirm private-state persistence works.
Restart the proof server and rerun one representative transaction.
Record proof-generation duration for the largest circuit.

Pass this section only when a real proof-generation flow succeeds against the environment you plan to use for deployment testing.

CI checklist

Add this checklist to pull requests that modify Compact source, TypeScript witnesses, generated smart contract code, package versions, Docker images, provider configuration, or deployment scripts.

## Midnight deployment security checklist

- [ ] `compact format --check src/` passes.
- [ ] `compact fixup --check src/` passes.
- [ ] Compact source recompiles from a clean generated directory.
- [ ] TypeScript type checking passes.
- [ ] Unit tests cover success paths and negative paths.
- [ ] Every `disclose()` call has a documented public reason.
- [ ] No raw private data appears in exported ledger fields.
- [ ] `ownPublicKey()` is absent from caller verification.
- [ ] Replay protection uses a nonce, nullifier, counter, or round.
- [ ] Witness return types match generated TypeScript types.
- [ ] Malicious witness tests fail safely.
- [ ] Versions match the compatibility matrix.
- [ ] Proof generation succeeds on local network, Preview, or Preprod.
- [ ] Public state after proof submission matches the exported ledger review.

Troubleshooting

The compiler reports a missing disclosure

Do not wrap the earliest private value in disclose() just to silence the compiler. Move disclose() to the public assignment or exported return. Then document the disclosure.

`ownPublicKey()` appears in authorization

Treat it as a blocker. Replace it with a commitment derived from localSecretKey() or another verified private input. Bind that commitment to a domain separator and replay boundary.

A replay test succeeds twice

Find the missing uniqueness boundary. Add a counter, round, nonce, or nullifier to the commitment derivation. Update or claim it after a successful call.

A sealed field fails compilation

Check whether an exported circuit modifies a sealed ledger field. Sealed fields belong to initialization logic. Use unsealed fields only when post-deployment mutation is required.

Proof generation fails but unit tests pass

Check version compatibility first. Confirm the Compact compiler, generated files, Compact runtime, Ledger version, Midnight.js packages, and proof server image target the same release. Then inspect circuit complexity and witness return types.

Port `6300` is unavailable

Stop the existing process or container using the port. If you remap the host port, update the DApp and Lace proof server configuration to match.

Deployment decision

Deploy only when the checklist produces evidence: command output, test results, source links, generated metadata, transaction hashes, and public ledger snapshots. A passing DApp has a clear disclosure policy, safe authorization, replay boundaries, reviewed public state, correct witnesses, compatible versions, and proof-generation coverage.

Next steps

After this checklist passes, publish the review notes with the release candidate. Include the Compact compiler version, Ledger version, proof server version, target environment, transaction hashes from testing, and the exported ledger review. Keep the checklist in the repository so future feature work cannot bypass it.

Midnight vs Other Privacy Chains: Architecture Comparison for Developers

Arihant Agarwal — Sun, 10 May 2026 23:19:18 +0000

Privacy-focused chains do not solve the same problem. Some focus on shielded payments. Some focus on private program execution. Some focus on recursive proofs and cheap verification. This tutorial compares Midnight, Aztec, Aleo, Mina, and Zcash from a developer point of view: what you write, where state lives, what the chain verifies, and where engineering friction appears.

This guide is for developers and Web3 enthusiasts who understand basic smart contract concepts and want a practical comparison of privacy-preserving stacks.

Prerequisites

You should know account and UTXO state models, zero-knowledge proof basics, and the lifecycle of deploying a smart contract or DApp.

What this comparison checks

Use three questions to compare these systems:

Language design: How do you express public values, private values, assertions, and proof-generating logic?
State model: Does state live in accounts, notes, records, local private state, public mappings, or commitment trees?
Privacy model: What does the chain hide, what does it reveal, and how does a developer control disclosure?

Midnight sits between programmable smart contracts and shielded asset movement. It uses Compact for smart contracts, ZK circuits for correctness, Kachina for data-protecting smart contract execution, Zswap for shielded multi-asset swaps, and a dual ledger approach that combines UTXO-style ledger tokens with account-style contract tokens.

A current Midnight baseline

Start with the smallest useful Compact example. The current Midnight Hello World tutorial uses Compact language version >= 0.23 and shows the main privacy boundary in one line: a private circuit parameter becomes public only through disclose().

pragma language_version >= 0.23;

export ledger message: Opaque<"string">;

export circuit storeMessage(newMessage: Opaque<"string">): [] {
  message = disclose(newMessage);
}

The ledger declaration creates on-chain state. Circuit parameters are private by default. disclose(newMessage) makes the value available for public storage. That explicit boundary is the key Compact habit: do not let private inputs become public by accident.

A typical setup flow follows the official example repository and compiler workflow:

git clone https://github.com/midnightntwrk/example-hello-world.git
cd example-hello-world
yarn install

cd contracts
compact compile hello-world.compact managed/hello-world.compact

For DApp interaction, you also run a proof server. The proof server generates ZK proofs for circuit calls before the transaction reaches the network.

docker run -p 6300:6300 midnightntwrk/proof-server:8.0.3 midnight-proof-server -v

That workflow shows Midnight's shape. You write Compact. The compiler validates the smart contract, emits ZK artifacts, and generates TypeScript-facing APIs. Midnight.js connects the compiled smart contract to providers for public data, private state, ZK artifacts, proof generation, wallet interaction, transaction submission, and logging.

Compact source
  -> compiler validation
  -> JavaScript circuit implementation
  -> TypeScript declarations
  -> ZK intermediate representation and keys
  -> Midnight.js providers
  -> proof server
  -> submitted transaction

Midnight: Compact, Kachina, Zswap, and the dual ledger

Midnight's developer model starts with Compact. Compact is not Solidity with a privacy library attached. It is a smart contract language that compiles to ZK circuits used to prove correctness of interactions with the ledger. That matters because you write application logic with proof generation in mind from the start.

Kachina explains the contract privacy model. Public state lives on-chain. Private state stays local to the user or application. A ZK proof connects the two by proving that a private state transition justifies a public state update. Validators do not need to learn the private witness. They verify the proof and the public part of the transaction.

That model feels different from an EVM account update. In a Solidity contract, the chain sees the call data unless you add a separate privacy mechanism. In Midnight, the default design pushes sensitive inputs into local execution and proof generation. You still need to decide what becomes public. The compiler does not remove the need for data classification. It makes the boundary explicit.

Zswap handles the asset side. It is a data-protecting transaction scheme for multi-asset atomic swaps. It draws from Zerocash and Zcash Sapling ideas, uses ZK proofs and commitments, and supports non-interactive merging of transactions. For developers, this means Midnight is not only about hiding smart contract inputs. It also gives a native path for shielded asset exchange and DeFi-style flows where pre-trade visibility can leak value.

Midnight also uses a dual ledger approach. Ledger tokens use a UTXO model. Contract tokens use an account-style model inside Compact smart contracts. That gives you two design paths. Use ledger tokens when you need shielded, UTXO-style asset movement. Use contract tokens when your application needs smart contract controlled state. The trade-off is that you must choose the right token model early. Migrating an application from one state assumption to another can change wallet UX, indexing, and proof flow.

The main strength is coherence. Compact, Midnight.js, the proof server, Kachina, and Zswap target the same application style: privacy-preserving DApps with explicit disclosure. The main friction is operational. You manage proof generation, private state, public data queries, network compatibility, and toolchain versions.

Aztec: Noir, Aztec.nr, PXE, and notes

Aztec is a privacy-first Ethereum Layer 2 that combines private and public execution. Developers write smart contracts in Noir through Aztec.nr. Private functions execute client-side and produce proofs. Public functions execute in the Aztec Virtual Machine. This split gives Aztec a strong programming model for applications that need both confidential user actions and public settlement.

Aztec's state model centers on notes. A note is an encrypted piece of private state. The protocol stores note hashes and uses nullifiers to prevent double spending. Public state sits in a public data tree. Private state behaves like a UTXO model: you create notes, consume notes, and reveal nullifiers when notes are spent. The user discovers and decrypts relevant notes through local tooling.

The PXE, or private execution environment, is central to the developer experience. It stores secrets, synchronizes relevant notes, prepares private function execution, and generates proofs before transaction submission. That gives developers a clear privacy boundary: private inputs stay in the PXE. It also creates a local-state dependency. If note discovery or PXE synchronization fails, the application can feel broken even when the chain is healthy.

Noir itself is broader than Aztec. It compiles to an intermediate representation that can target proving backends. Aztec.nr adds the blockchain-specific layer: macros, storage abstractions, contract patterns, and execution conventions. If you already think in ZK circuits, Noir is attractive because it exposes a general ZK programming language. If you come from account-based smart contracts, the note lifecycle is the larger adjustment.

A minimal Aztec.nr private counter shows the model. The private function updates note-backed state for an owner, while the utility function reads local private state through the PXE.

use aztec::macros::aztec;

#[aztec]
pub contract Counter {
    use aztec::{
        macros::{functions::{external, initializer}, storage::storage},
        messages::message_delivery::MessageDelivery,
        protocol::address::AztecAddress,
        state_vars::Owned,
    };
    use balance_set::BalanceSet;

    #[storage]
    struct Storage<Context> {
        counters: Owned<BalanceSet<Context>, Context>,
    }

    #[initializer]
    #[external("private")]
    fn initialize(owner: AztecAddress, start: u64) {
        self.storage.counters.at(owner).add(start as u128).deliver(
            MessageDelivery.ONCHAIN_CONSTRAINED,
        );
    }

    #[external("private")]
    fn increment(owner: AztecAddress) {
        self.storage.counters.at(owner).add(1).deliver(MessageDelivery.ONCHAIN_CONSTRAINED);
    }

    #[external("utility")]
    unconstrained fn get_counter(owner: AztecAddress) -> pub u128 {
        self.storage.counters.at(owner).balance_of()
    }
}

Aztec is strong when an application needs Ethereum-adjacent settlement, programmable private actions, and a clean split between private and public functions. The cost is complexity around notes, PXE state, asynchronous execution, and the mental shift from updating contract storage to consuming and creating private commitments.

Aleo: Leo, records, transitions, and mappings

Aleo uses Leo as its developer-facing language. Leo looks like a domain-specific language for ZK applications rather than a general smart contract language. It gives developers records for private state and mappings for public state.

A record is Aleo's private state container. It can hold arbitrary application data. Records are encrypted on-chain, owned by an address, and consumed when used. A transition can consume old records and create new records. This mirrors the UTXO lifecycle: state changes by spending old objects and producing new objects, not by mutating a global account balance in place.

Public state uses mappings. Mappings are visible on-chain and suit counters, registries, configuration, and other shared values. Leo also supports finalizers for public state updates after private execution. The result is a hybrid model. Private data flows through records. Public coordination flows through mappings.

In Leo, the split is visible in the syntax: records carry private state, mappings carry public state, and an async finalizer updates the mapping.

program private_points.aleo {
    mapping public_points: address => u64;

    record Points {
        owner: address,
        amount: u64,
    }

    transition mint_private(receiver: address, amount: u64) -> Points {
        return Points {
            owner: receiver,
            amount: amount,
        };
    }

    async transition publish(points: Points) -> Future {
        return finalize_publish(points.owner, points.amount);
    }

    async function finalize_publish(owner: address, amount: u64) {
        let current: u64 = Mapping::get_or_use(public_points, owner, 0u64);
        Mapping::set(public_points, owner, current + amount);
    }
}

Aleo fits applications whose state maps to private record ownership. The hard parts are shared mutable state, coordination, indexing, and recovery because each user depends on finding, decrypting, and spending the right records.

Compared with Midnight, Aleo puts more emphasis on records as the unit of private program state. Midnight puts more emphasis on the relationship between local private state, public ledger state, and smart contract calls.

Mina: o1js, zkApps, and recursive proofs

Mina approaches privacy and scalability from a different angle. Its signature feature is recursive proof composition. The chain itself uses recursive proofs to keep verification small. Developers build zkApps with o1js, a TypeScript library for writing ZK circuits and smart contracts.

The developer experience is familiar if you already use TypeScript. You define a smart contract class, add methods, use o1js field types, and generate proofs locally. The network verifies the proof and applies account updates. On-chain state is intentionally small. A zkApp account has a limited number of on-chain fields, so applications often keep larger state off-chain and commit to it with hashes or Merkle roots.

Privacy in Mina is about what the proof hides. Method parameters and computation can remain private, while the public account update reveals the verified state change. Mina is less natural for rich native shielded asset flows or large private state directly represented on-chain.

Mina's best developer story is proof composition. You can build a proof of a computation, then use recursion to fold proofs together or verify one proof inside another. For identity, games, compliance checks, and verifiable compute, this can be more important than a full shielded transaction system. The trade-off is that you design around small public state and off-chain data availability.

An o1js contract looks like TypeScript, but the method body builds constraints. Here, the public state stores only a commitment. The secret argument stays private inside the proof.

import { Field, Poseidon, SmartContract, State, method, state } from 'o1js';

export class HashCounter extends SmartContract {
  @state(Field) commitment = State<Field>();

  init() {
    super.init();
    this.commitment.set(Poseidon.hash([Field(0)]));
  }

  @method async incrementSecret(secret: Field) {
    const current = this.commitment.get();
    this.commitment.requireEquals(current);

    Poseidon.hash([secret]).assertEquals(current);
    this.commitment.set(Poseidon.hash([secret.add(1)]));
  }
}

Compared with Midnight, Mina gives you a TypeScript proving environment and a strong recursive proof story. Midnight gives you a domain-specific smart contract language, a proof server workflow, and native shielded asset architecture through Zswap.

Zcash Sapling: shielded payments, not general DApps

Zcash Sapling is the reference point for shielded payment privacy. Sapling improved shielded transaction efficiency, introduced Sapling shielded addresses, and supports viewing keys that let a holder disclose transaction details without giving spend authority.

The Sapling state model uses note commitments and nullifiers. A shielded output creates a note commitment. A spend reveals a nullifier so the network can reject double spends without learning which note was spent. The protocol can hide sender, receiver, amount, and memo data for shielded transfers, while fees and some transaction metadata remain visible.

For developers, Zcash is not a general-purpose privacy-preserving smart contract platform. It is a payment protocol and wallet ecosystem. You build wallets, exchanges, payment flows, custody tools, compliance flows, and viewing-key workflows. You do not write arbitrary DApps that update application state through smart contract circuits.

The developer surface is therefore RPC and wallet integration. A Sapling-oriented flow creates an account, derives a shielded receiver, sends with a privacy policy, and checks the async operation.

zcash-cli z_getnewaccount
zcash-cli z_getaddressforaccount ACCOUNT_NUMBER '["sapling"]'
zcash-cli z_sendmany "FROM_SHIELDED_OR_UNIFIED_ADDRESS" \
  '[{"address":"RECIPIENT_SHIELDED_OR_UNIFIED_ADDRESS","amount":0.01,"memo":"48656c6c6f"}]' \
  10 null FullPrivacy
zcash-cli z_getoperationstatus '["OPERATION_ID"]'

That makes Zcash a clean comparison point. It shows mature shielded payment privacy, but not programmable private application logic. If the product is a privacy-preserving application with custom logic, you need one of the programmable stacks.

Developer experience comparison

Stack	Language design	State model	Privacy model	Best fit	Main friction
Midnight	Compact smart contracts compile to ZK circuits and TypeScript-facing artifacts.	Public ledger state, local private state, UTXO-style ledger tokens, and account-style contract tokens.	ZK proofs connect local private state to public updates. Zswap supports shielded multi-asset swaps.	Privacy-preserving DApps that need smart contract logic and shielded assets.	Toolchain compatibility, proof server setup, private state handling, and token model choice.
Aztec	Noir plus Aztec.nr for private and public smart contract functions.	Public data tree plus encrypted notes and nullifiers.	Private functions run client-side through PXE. Public functions run in the AVM.	Ethereum-adjacent applications with private actions and public settlement.	Note discovery, PXE sync, asynchronous private/public flows, and non-EVM design.
Aleo	Leo programs with transitions, records, mappings, and finalizers.	Private records and public mappings.	Records are encrypted and spent like private UTXOs. Public mappings support shared state.	Private-by-default applications where user-owned records are natural.	Record lifecycle management, shared state coordination, and indexing.
Mina	o1js TypeScript smart contracts and ZK programs.	Small on-chain account state, off-chain data, and committed roots.	Proofs hide private inputs and computation while public account updates settle on-chain.	Recursive proof applications and succinct verification of off-chain compute.	Limited on-chain state, proof design, and off-chain data management.
Zcash Sapling	Protocol-level shielded payment logic, not a smart contract language.	Note commitments, nullifiers, shielded addresses, and transparent addresses.	Shielded transfers hide sender, receiver, amount, and memo data. Viewing keys support disclosure.	Payments, wallets, custody, and shielded transfer workflows.	No general smart contract layer for application logic.

How to choose

Choose Midnight when your DApp needs privacy-preserving smart contract logic and shielded asset movement in the same architecture. Compact gives you explicit disclosure control. Zswap gives you shielded multi-asset exchange. The dual ledger gives you a choice between UTXO-style ledger tokens and account-style smart contract tokens.

Choose Aztec when your application benefits from Ethereum Layer 2 settlement and you can accept the note-based private state model. Aztec is a strong fit for applications that need both private user actions and public composability.

Choose Aleo when your product state maps cleanly to private records. It works well when users own private objects, spend them, and receive new ones as the application evolves.

Choose Mina when the application centers on proving off-chain computation and composing proofs. Mina is less about shielded asset flows and more about succinct verification.

Choose Zcash when the requirement is shielded payment privacy rather than programmable DApp logic.

Troubleshooting common mistakes

Version mismatch: Compact examples depend on language and toolchain versions. Match the pragma language_version directive to the installed Compact toolchain and the current Midnight compatibility matrix.

Proof server unavailable: Midnight DApp calls that require proofs need a reachable proof server or proof provider. Check the host, port, Docker status, and ZK artifact path before debugging wallet code.

Accidental disclosure: Treat disclose() as a security review point. Every disclosed value becomes part of the public logic. If a value should stay private, keep it in the witness path or local private state.

Wrong token model: Ledger tokens and contract tokens do not give the same developer experience. Use the UTXO-style path for shielded asset movement and the account-style path for smart contract managed tokens.

Lost local state: Aztec notes, Aleo records, and Midnight private state all depend on local discovery or storage. Plan backup, recovery, and indexing before users hold value.

Overusing ZK: A proof hides inputs and computation, but it does not hide everything. Timing, fees, public state changes, nullifiers, commitments, and application-level messages can still leak information.

References

Getting NIGHT Tokens: Exchanges, Bridging & Wallet Funding on Mainnet: An Overview

Arihant Agarwal — Sun, 10 May 2026 22:55:11 +0000

NIGHT is the unshielded native and governance token of Midnight. It gives users and developers access to the network resource model that powers transactions on Midnight. This tutorial explains where you can acquire NIGHT, how to withdraw it safely, how to prepare a Midnight-compatible wallet, and what the Cardano-to-Midnight bridge supports today.

Use this guide if you want to buy NIGHT, move it into self-custody, generate DUST, or prepare for Midnight Mainnet activity.It is best suited for:

Users who want to buy and hold NIGHT.
Developers who need NIGHT and DUST for testing or Mainnet usage.
Builders who need to explain the current NIGHT wallet and bridge flow to their users.

Prerequisites

Before you start, make sure you have:

An account on an exchange that lists NIGHT, or access to a Cardano DEX.
A Cardano wallet that supports Cardano Native Assets.
A Midnight-compatible wallet, such as Lace, if you want to use Midnight Mainnet.
A small amount of ADA in your Cardano wallet for Cardano transaction fees.
The official NIGHT policy ID on Cardano:

0691b2fecca1ac4f53cb6dfb00b7013e561d1f34403b957cbb5af1fa4e49474854

This tutorial contains no Compact code. It only covers token acquisition, wallet preparation, withdrawal checks, and bridge status.

Understand NIGHT and DUST

Midnight uses a dual-component token model.

NIGHT is the public token. It is unshielded, visible on-chain, and used for governance, network security, and DUST generation. DUST is the shielded network resource that pays for transaction capacity on Midnight. You spend DUST to use Midnight, but you do not buy it as a normal transferable token.

The difference matters when you use an exchange. Exchanges list NIGHT. They do not list DUST as a token you can buy, withdraw, or transfer. DUST is generated from NIGHT balances and is used as a consumable resource for transactions and smart contract execution.

Midnight documentation describes NIGHT as a token that exists across Cardano and Midnight. On Cardano, NIGHT is a Cardano Native Asset. On Midnight, NIGHT is a native token on Midnight. The protocol keeps supply consistent by locking NIGHT on one chain when it is unlocked on the other.

Where to get NIGHT

You can acquire NIGHT through three main paths.

Option 1: Buy NIGHT on a centralized exchange

A centralized exchange is the simplest path for most users. You create an account, complete any required identity checks, deposit funds, buy NIGHT, and withdraw to self-custody when withdrawals are available.

The official Midnight NIGHT page lists exchange partners that include:

Exchange	Typical market to check
Binance	`NIGHT/USDT` or supported local pairs
Bitpanda	App-based NIGHT markets where available
Bitrue	`NIGHT/USDT`
Bybit	`NIGHT/USDT`
Gate	`NIGHT/USDT`
HTX	`NIGHT/USDT`
Kraken	`NIGHT/USD` or other supported fiat pairs
KuCoin	`NIGHT/USDT`
LBank	`NIGHT/USDT`
MEXC	`NIGHT/USDT` or `NIGHT/USDC`
OKX	`NIGHT/USDT`
eToro	App-based NIGHT markets where available

Market availability changes by region, account type, and exchange policy. Before you buy, open the exchange's deposit and withdrawal page for NIGHT. Confirm that the exchange supports withdrawals, not just trading. Some venues list a token before withdrawals are available, and some pause withdrawals during maintenance.

A good exchange choice is not only the exchange with the lowest trading fee. It is the venue that supports your region, has enough liquidity, allows withdrawals, and clearly shows the withdrawal network.

Option 2: Swap for NIGHT on Cardano

You can also acquire NIGHT through Cardano DEX liquidity when routes are available. This path keeps you in self-custody from the start, but it requires careful asset verification.

Before you swap:

Open the DEX or aggregator you plan to use.
Search for NIGHT by policy ID, not only by token name.
Confirm the policy ID is:

0691b2fecca1ac4f53cb6dfb00b7013e561d1f34403b957cbb5af1fa4e49474854

Check the route, price impact, and slippage.
Confirm the transaction in your Cardano wallet.

Do not rely on the ticker alone. Cardano allows different assets to use similar names. The policy ID is the reliable identifier.

Option 3: Redeem previously claimed NIGHT

Some users received NIGHT through distribution programs such as Glacier Drop, Scavenger Mine, or later redemption phases. If you participated in one of these programs, use the official redemption flow and follow the instructions for your claim type.

The official NIGHT page states that the total supply is 24,000,000,000 NIGHT and that the distribution includes a thawing period. If you redeem distribution tokens, check whether your balance is available immediately or subject to the thawing schedule.

Choose the right wallet

You need to separate two wallet tasks.

The first task is receiving NIGHT from an exchange or DEX. For that, use a Cardano wallet that supports Cardano Native Assets if the withdrawal network is Cardano. The address must be a Cardano wallet address.

The second task is using Midnight Mainnet. For that, use a Midnight-compatible wallet. Lace supports Midnight Mainnet inside the Lace extension and lets you manage public and shielded Midnight assets, generate DUST, and connect to Midnight DApps.

Do not paste a Midnight wallet address into a Cardano withdrawal form. Do not paste a Cardano wallet address into a Midnight-only transfer form. The address must match the network used by the sender.

Set up a Midnight wallet in Lace

Use this flow if you want to prepare a Midnight wallet in Lace.

Install or update the Lace browser extension.
Open Lace.
Select Create new wallet.
Select Midnight.
Choose whether to reuse an existing recovery phrase or create a new one.
Store the recovery phrase offline.
Re-enter the recovery phrase if Lace asks you to confirm it.
Name the wallet and set a password.
Select Mainnet.
Choose the proof server option you want to use.
Select Enter wallet.

A proof server generates ZK proofs for Midnight transactions. Lace support explains that you can run a local proof server or connect to a remote service. Use the option that matches your security needs and technical comfort level.

Withdraw NIGHT from an exchange

Follow these steps when your exchange supports NIGHT withdrawals on Cardano.

Step 1: Confirm the withdrawal network

Open the NIGHT withdrawal page on the exchange and check the network field. If the exchange offers Cardano as the withdrawal network, prepare a Cardano receiving address.

If the exchange offers Midnight Mainnet as a withdrawal network, confirm that your receiving wallet supports Midnight Mainnet and that the address format matches the exchange instructions. Do not assume Midnight withdrawals exist unless the exchange shows the network explicitly.

Step 2: Copy a Cardano receiving address

Open your Cardano wallet and copy a fresh receiving address. Make sure the wallet can display Cardano Native Assets.

Keep some ADA in the wallet. Cardano transactions require ADA for fees and may require minimum ADA values for token UTXOs.

Step 3: Send a small test withdrawal

Start with a small amount of NIGHT. This costs an extra withdrawal fee, but it protects you from sending the full balance to the wrong network or an unsupported wallet.

After the exchange processes the withdrawal, check your wallet. Confirm that the received asset uses the official NIGHT policy ID.

Step 4: Withdraw the remaining balance

After the test withdrawal arrives, send the remaining amount. Save the transaction hash and exchange withdrawal record.

If your wallet does not update right away, use the transaction hash in a Cardano explorer and confirm the asset, destination address, and amount.

Step 5: Prepare for Midnight usage

After NIGHT reaches your Cardano wallet, set up or open your Midnight wallet. To use Midnight transactions, you need DUST capacity. You can generate DUST by designating NIGHT to a Midnight address, or you can use a DApp that sponsors your transactions.

Understand designation

Designation associates NIGHT with a Midnight address so it can generate DUST for that address. Without designation, your NIGHT does not generate DUST for that Midnight wallet.

Lace support describes two related actions:

Designating: You use your NIGHT to generate DUST for a chosen Midnight wallet.
Receiving a designation: Another party designates NIGHT so DUST is generated for your address. A DApp can use this pattern to sponsor user transactions.

Designation helps separate ownership from usage. For example, a developer can hold NIGHT and designate DUST capacity to users so the DApp feels free at the point of interaction.

Understand the Cardano-to-Midnight bridge

Midnight maintains interoperability with Cardano through a native bridge model. For NIGHT, the core rule is supply consistency. NIGHT cannot be freely duplicated across both chains. When NIGHT is active on one chain, it is locked on the other.

For users, the current experience has an important limitation. Lace support states that, for the moment, you cannot send NIGHT from a Cardano wallet or centralized exchange account directly to a Midnight wallet because Cardano and Midnight are different blockchains. Work is in progress to enable this feature.

This means you should treat three actions as separate:

Holding NIGHT on Cardano.
Designating NIGHT so it generates DUST for a Midnight address.
Moving NIGHT itself onto Midnight when supported by your wallet, exchange, or bridge interface.

Do not combine these actions in your head. A Cardano withdrawal is not the same as a Midnight transfer, and DUST generation is not the same as moving NIGHT.

What does not exist yet

Some user flows are still maturing.

Direct Cardano or exchange transfers to a Midnight wallet are not the default

The safest assumption is that exchange withdrawals use Cardano unless the exchange clearly shows Midnight Mainnet as a supported withdrawal network. Lace support still warns that direct transfers from a Cardano wallet or CEX account to a Midnight wallet are not available in that Lace flow.

DUST is not a market token

DUST is not a transferable token that you buy, sell, or withdraw from an exchange. It is a shielded resource for transaction capacity. It is generated from NIGHT, can decay, and is consumed when you use Midnight.

Wallet support is not uniform

A wallet can support Cardano Native Assets without supporting Midnight Mainnet. A different wallet can support Midnight Mainnet but still depend on separate Cardano flows for NIGHT acquisition. Check the exact feature before you move funds.

Bridge UX is still evolving

Midnight documentation describes native bridge support, and Lace support describes current limits in the direct user flow. Until your wallet or exchange provides a clear bridge interface, avoid manual transfers between chains.

What is coming

Midnight Mainnet is live, and the ecosystem is moving through a phased rollout. The April 2026 network update describes the period after launch as an application and ecosystem expansion phase. Wallet support, DUST generation tools, DApp onboarding, and bridge UX are expected to improve as more services come online.

For developers, the most important coming improvement is smoother onboarding. A DApp can sponsor user activity by designating DUST capacity to user addresses. This pattern lets users try a Midnight DApp without buying NIGHT first. It also lets builders hide token mechanics behind a clearer product experience.

If you build on Midnight, design your onboarding around capability checks:

Detect whether the user has a Midnight wallet.
Detect whether the wallet has DUST capacity.
Explain when NIGHT designation is required.
Sponsor the first transaction when your DApp supports it.
Show clear recovery and proof server guidance.

Troubleshooting

The exchange lists NIGHT, but withdrawals are disabled

Wait for withdrawals to open, or use a venue that supports withdrawals in your region. Do not buy on a venue if your goal is self-custody and the exchange does not provide a withdrawal path.

NIGHT does not appear in my wallet

Check the transaction hash in a Cardano explorer. Confirm the withdrawal used the Cardano network, the destination address is correct, and the asset policy ID matches the official NIGHT policy ID.

Some wallets hide new tokens by default. Check the wallet's token list settings if the transaction is confirmed but the asset does not appear in the main balance view.

I have NIGHT, but I cannot transact on Midnight

You need DUST capacity for Midnight transactions. Designate NIGHT to your Midnight address, wait for DUST generation to begin, or use a DApp that sponsors your transaction capacity.

I copied the wrong address type

Stop before you confirm the transaction. A Cardano withdrawal needs a Cardano wallet address. A Midnight transaction needs a Midnight wallet address. If you already submitted the withdrawal, contact the exchange or wallet support team and provide the transaction hash.

I want to use Midnight without buying NIGHT

You can use Midnight when a DApp sponsors your transaction capacity or when another party designates NIGHT to your Midnight address. This depends on the DApp and wallet support. Check the DApp's onboarding flow before you assume sponsorship is available.

Security checklist

Before you move funds, confirm each item:

The asset policy ID matches the official NIGHT policy ID.
The withdrawal network matches the receiving wallet.
The wallet supports the asset you are receiving.
You have enough ADA for Cardano fees if you use Cardano.
You saved the recovery phrase for your wallet.
You tested the withdrawal with a small amount first.
You saved the transaction hash.

Next steps

Start with a small NIGHT purchase or swap. Withdraw to a Cardano wallet if the exchange uses Cardano as the withdrawal network. Verify the policy ID, then set up a Midnight wallet in Lace or another Midnight-compatible wallet.

After that, learn how designation works. Designation is the bridge between holding NIGHT and having usable DUST capacity on Midnight. Once your wallet has DUST capacity, you can connect to Midnight DApps and start using Mainnet with fewer surprises.

Related resources

Running a Midnight Node: Setup, Sync & Monitoring: An In-depth Tutorial

Arihant Agarwal — Sun, 10 May 2026 22:40:08 +0000

Set up a Midnight full node from scratch, monitor sync, troubleshoot peers, and verify node health with Docker, RPC, and logs.

This tutorial is for developers and node operators who want to run a Midnight full node, watch it sync, keep it healthy, and diagnose the common failure mode where a node stays on block 1 while peers connect and disconnect.

You do not need to run a proof server for a full node. A proof server generates ZK proofs for smart contract workflows. A full node syncs chain state, validates blocks and transactions, exposes local RPC if you enable it, and joins the P2P network.

Since this is a hands-on tutorial, we will dive straight into it without much chatter. I'm sure you're here because you can't wait to deploy!

What you will build

You will build a single-host operator setup with these services:

A Cardano node
Cardano-db-sync
PostgreSQL for Cardano-db-sync
A Midnight full node
Local RPC and Prometheus endpoints bound to 127.0.0.1

The default path in this guide targets the Preview environment. Preview is best for early development and operator practice. Change the network variables for Preprod or Mainnet only after you check the current compatibility matrix.

How Midnight full nodes fit into the network

A Midnight node implements core protocol logic, manages P2P networking, and supports decentralized operation as a Cardano Partnerchain. It also runs the Midnight Ledger component, enforces protocol rules, maintains state integrity, discovers peers, establishes connections, and gossips state across the network.

A full node and an archive node differ mainly in state retention:

A full node syncs the blockchain, validates transactions, serves real-time state queries, and prunes older historical state. The default pruning window in the official docs is 256 blocks.
An archive node keeps the full block and state history. Use it for explorers, historical debugging, analytics, or services that need past state at arbitrary heights.

Use a full node unless you have a clear archive use case. Archive mode increases storage use and operational cost.

Prerequisites

Use a Linux host for production or serious operator testing. The commands below assume Ubuntu 22.04 LTS or Ubuntu 24.04 LTS.

You need:

sudo access
A stable internet connection
Inbound TCP 30333 open for P2P traffic
Outbound HTTPS and P2P access
Docker Engine and the Docker Compose plugin
jq, curl, openssl, psql, and nc
Enough CPU, RAM, disk, and IOPS for Cardano-db-sync and the Midnight node

Do not use latest image tags. Pin the node image for the network you run.

Choose the network and image version

The values below reflect the public Midnight compatibility information available at the time of writing. Always check the release compatibility matrix before you start or upgrade.

Environment	Use case	Node image
Preview	Early development and operator testing	`midnightntwrk/midnight-node:0.22.5`
Preprod	Final testing before Mainnet deployment	`midnightntwrk/midnight-node:0.22.2`
Mainnet	Production network	`midnightntwrk/midnight-node:0.22.1`

This tutorial uses Preview:

cat > midnight.env <<'EOF'
MIDNIGHT_NETWORK=preview
MIDNIGHT_NODE_VERSION=0.22.5
MIDNIGHT_NODE_IMAGE=midnightntwrk/midnight-node:0.22.5
CARDANO_NETWORK=preview
MIDNIGHT_BOOTNODE_1=/dns/bootnode-1.preview.midnight.network/tcp/30333/ws/p2p/12D3KooWK66i7dtGVNSwDh9tTeqov1q6LSdWsRLJvTyzTCaywYgK
MIDNIGHT_BOOTNODE_2=/dns/bootnode-2.preview.midnight.network/tcp/30333/ws/p2p/12D3KooWHqFfXFwb7WW4jwR8pr4BEf562v5M6c8K3CXAJq4Wx6ym
EOF

For Preprod, use this file instead:

cat > midnight.env <<'EOF'
MIDNIGHT_NETWORK=preprod
MIDNIGHT_NODE_VERSION=0.22.2
MIDNIGHT_NODE_IMAGE=midnightntwrk/midnight-node:0.22.2
CARDANO_NETWORK=preprod
MIDNIGHT_BOOTNODE_1=/dns/bootnode-1.preprod.midnight.network/tcp/30333/ws/p2p/12D3KooWQxxUgq7ndPfAaCFNbAxtcKYxrAzTxDfRGNktF75SxdX5
MIDNIGHT_BOOTNODE_2=/dns/bootnode-2.preprod.midnight.network/tcp/30333/ws/p2p/12D3KooWNrUBs22FfmgjqFMa9ZqKED2jnxwsXWw5E4q2XVwN35TJ
EOF

Mainnet operators should use the Mainnet image from the compatibility matrix and the Mainnet boot node configuration published for the current release. Do not reuse Preview or Preprod boot nodes on Mainnet.

Some docs, older guides, and community posts may mention testnet-02 and the old midnightnetwork/midnight-node image. Do not mix those values with Preview, Preprod, or Mainnet. A mismatched image, boot node, or chain spec is one of the fastest ways to get a node that starts but never syncs.

Size the host

Size the machine for the slowest component, which is usually Cardano-db-sync during initial catch-up. The official Cardano-db-sync guidance for Midnight lists these lower bounds:

Component	Preview minimum	Mainnet minimum
CPU	4 cores	4 cores
RAM	16 GB	32 GB
Disk for Cardano-db-sync	40 GB SSD	320 GB SSD
IOPS	30,000 or better	60,000 or better

Use these as the floor, not the target. A combined node host also needs space for the Midnight chain database, Docker layers, PostgreSQL growth, logs, and backups.

Recommended starting sizes:

Role	CPU	RAM	Storage	Notes
Preview full node	4 vCPU	16 GB	150 GB SSD	Good for development and testing
Preview full node with headroom	8 vCPU	32 GB	250 GB NVMe	Better for stable long-running service
Mainnet full node	8 vCPU	32 GB or more	500 GB NVMe	Treat this as a practical floor
Archive node	8 vCPU or more	32 GB or more	1 TB NVMe or more	Monitor growth and plan expansion

Avoid HDD storage. A slow disk causes long sync times, peer churn, PostgreSQL stalls, and failed restarts after unclean shutdowns.

Install system packages

Run the setup from a clean host:

sudo apt-get update
sudo apt-get install -y \
  ca-certificates \
  curl \
  gnupg \
  jq \
  lsb-release \
  netcat-openbsd \
  openssl \
  postgresql-client

Install Docker Engine and the Docker Compose plugin:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

. /etc/os-release
printf '%s\n' \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu ${VERSION_CODENAME} stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install -y \
  containerd.io \
  docker-buildx-plugin \
  docker-ce \
  docker-ce-cli \
  docker-compose-plugin

Allow your user to run Docker commands:

sudo usermod -aG docker "$USER"
newgrp docker

Verify the installation:

docker --version
docker compose version
docker run --rm hello-world

Create the working directory

Keep node files in a dedicated directory. This makes backups, resets, and audits easier.

sudo mkdir -p /opt/midnight-node
sudo chown "$USER:$USER" /opt/midnight-node
cd /opt/midnight-node

Create the PostgreSQL environment file. The password is random hex, so it is safe to source in shell commands without escaping issues. The database connection string uses the same password as the PostgreSQL service.

umask 077
POSTGRES_PASSWORD="$(openssl rand -hex 24)"

cat > postgres.env <<EOF
POSTGRES_HOST=postgres
POSTGRES_PORT=5432
POSTGRES_USER=midnight
POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
POSTGRES_DB=cexplorer
DB_SYNC_POSTGRES_CONNECTION_STRING=psql://midnight:${POSTGRES_PASSWORD}@postgres:5432/cexplorer
EOF

Load both environment files:

set -a
. ./midnight.env
. ./postgres.env
set +a

Start Cardano-db-sync

Midnight nodes need a persistent connection to Cardano-db-sync. Start the Cardano side first and let it sync.

Create cardano-db-sync.compose.yml:

cat > cardano-db-sync.compose.yml <<'YAML'
networks:
  midnight-node-net:
    name: midnight-node-net

volumes:
  cardano-ipc: {}
  db-sync-data: {}
  postgres-data: {}

services:
  cardano-node:
    image: ${CARDANO_IMAGE:-ghcr.io/intersectmbo/cardano-node:10.5.3}
    platform: linux/amd64
    restart: unless-stopped
    container_name: cardano-node
    ports:
      - "3001:3001"
    environment:
      - NETWORK=${CARDANO_NETWORK}
      - CARDANO_NODE_SOCKET_PATH=/ipc/node.socket
    volumes:
      - cardano-ipc:/ipc
      - ./cardano-data:/data
    networks:
      - midnight-node-net

  postgres:
    image: postgres:15.3
    platform: linux/amd64
    restart: unless-stopped
    container_name: db-sync-postgres
    environment:
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
    volumes:
      - postgres-data:/var/lib/postgresql/data
    ports:
      - "127.0.0.1:${POSTGRES_PORT}:5432"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 5s
      retries: 20
    networks:
      - midnight-node-net

  cardano-db-sync:
    image: ghcr.io/intersectmbo/cardano-db-sync:13.6.0.5
    platform: linux/amd64
    restart: unless-stopped
    container_name: cardano-db-sync
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      - NETWORK=${CARDANO_NETWORK}
      - POSTGRES_HOST=${POSTGRES_HOST}
      - POSTGRES_PORT=${POSTGRES_PORT}
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - cardano-ipc:/node-ipc
      - db-sync-data:/var/lib
    networks:
      - midnight-node-net
YAML

Start the services:

docker compose \
  --env-file postgres.env \
  --env-file midnight.env \
  -f cardano-db-sync.compose.yml \
  up -d

Check container status:

docker compose \
  --env-file postgres.env \
  --env-file midnight.env \
  -f cardano-db-sync.compose.yml \
  ps

Follow logs while Cardano-db-sync catches up:

docker logs -f cardano-db-sync

Query Cardano-db-sync progress:

docker exec -e PGPASSWORD="${POSTGRES_PASSWORD}" db-sync-postgres \
  psql -U "${POSTGRES_USER}" -d "${POSTGRES_DB}" -tAc \
  "SELECT 100 * (
      EXTRACT(EPOCH FROM (MAX(time) AT TIME ZONE 'UTC')) -
      EXTRACT(EPOCH FROM (MIN(time) AT TIME ZONE 'UTC'))
    ) / (
      EXTRACT(EPOCH FROM (NOW() AT TIME ZONE 'UTC')) -
      EXTRACT(EPOCH FROM (MIN(time) AT TIME ZONE 'UTC'))
    ) AS sync_percent
    FROM block;"

Wait until the value is close to 100. The exact number may fluctuate near the tip. The Midnight node can start before this completes, but it may report mainchain follower errors or stay near the first blocks until Cardano-db-sync is usable.

Pull and inspect the Midnight node image

Pull the pinned image:

docker pull "${MIDNIGHT_NODE_IMAGE}"

Confirm that the image contains the chain resources for your environment:

docker run --rm \
  --entrypoint ls \
  "${MIDNIGHT_NODE_IMAGE}" \
  "/res/${MIDNIGHT_NETWORK}"

You should see files such as chain-spec-raw.json, chain-spec.json, and pc-chain-config.json. Stop if the directory is missing. A missing chain resource usually means the image version and network do not match.

Start the Midnight full node

Create the node volume:

docker volume create midnight-node-data

Start the full node:

docker run -d \
  --name midnight-full-node \
  --platform linux/amd64 \
  --restart unless-stopped \
  --network midnight-node-net \
  -p 30333:30333 \
  -p 127.0.0.1:9944:9944 \
  -p 127.0.0.1:9615:9615 \
  -v midnight-node-data:/node \
  -e "CFG_PRESET=${MIDNIGHT_NETWORK}" \
  -e "DB_SYNC_POSTGRES_CONNECTION_STRING=${DB_SYNC_POSTGRES_CONNECTION_STRING}" \
  "${MIDNIGHT_NODE_IMAGE}" \
  --chain="/res/${MIDNIGHT_NETWORK}/chain-spec-raw.json" \
  --base-path=/node/chain \
  --listen-addr=/ip4/0.0.0.0/tcp/30333 \
  --name="midnight-full-node" \
  --rpc-external \
  --rpc-methods=Safe \
  --prometheus-external \
  --bootnodes "${MIDNIGHT_BOOTNODE_1}" \
  --bootnodes "${MIDNIGHT_BOOTNODE_2}" \
  --no-private-ip

This binds the RPC endpoint to 127.0.0.1:9944 on the host, even though the node listens on all interfaces inside the container. Keep RPC private unless you put it behind explicit access control.

Follow the logs:

docker logs -f midnight-full-node

You want to see peer discovery, block import, and continuing progress. Do not judge the node from the first minute. Initial startup includes database creation, chain spec loading, peer discovery, and mainchain follower checks.

Run an archive node instead

Use archive mode only when you need historical state. Start from a clean Midnight data volume when switching between full and archive mode.

docker rm -f midnight-full-node || true
docker volume rm midnight-node-data || true
docker volume create midnight-node-data

docker run -d \
  --name midnight-archive-node \
  --platform linux/amd64 \
  --restart unless-stopped \
  --network midnight-node-net \
  -p 30333:30333 \
  -p 127.0.0.1:9944:9944 \
  -p 127.0.0.1:9615:9615 \
  -v midnight-node-data:/node \
  -e "CFG_PRESET=${MIDNIGHT_NETWORK}" \
  -e "DB_SYNC_POSTGRES_CONNECTION_STRING=${DB_SYNC_POSTGRES_CONNECTION_STRING}" \
  "${MIDNIGHT_NODE_IMAGE}" \
  --chain="/res/${MIDNIGHT_NETWORK}/chain-spec-raw.json" \
  --base-path=/node/chain \
  --listen-addr=/ip4/0.0.0.0/tcp/30333 \
  --name="midnight-archive-node" \
  --rpc-external \
  --rpc-methods=Safe \
  --prometheus-external \
  --bootnodes "${MIDNIGHT_BOOTNODE_1}" \
  --bootnodes "${MIDNIGHT_BOOTNODE_2}" \
  --pruning archive \
  --no-private-ip

Monitor sync and block height

The health endpoint gives a quick process check:

curl -fsS http://127.0.0.1:9944/health

Use JSON-RPC for node status:

curl -fsS \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"system_health","params":[],"id":1}' \
  http://127.0.0.1:9944 \
  | jq .

Example shape:

{
  "jsonrpc": "2.0",
  "result": {
    "peers": 8,
    "isSyncing": false,
    "shouldHavePeers": true
  },
  "id": 1
}

Check the latest local block:

curl -fsS \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"chain_getBlock","params":[],"id":1}' \
  http://127.0.0.1:9944 \
  | jq -r '.result.block.header.number'

The block number is hexadecimal. Convert it to decimal:

LOCAL_HEIGHT_HEX=$(curl -fsS \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"chain_getBlock","params":[],"id":1}' \
  http://127.0.0.1:9944 \
  | jq -r '.result.block.header.number')

printf '%d\n' "$((LOCAL_HEIGHT_HEX))"

Create a reusable RPC helper:

cat > rpc.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

RPC_URL="${1:-http://127.0.0.1:9944}"
METHOD="${2:-system_health}"
PARAMS="${3:-[]}"

curl -fsS \
  -H "Content-Type: application/json" \
  -d "{\"jsonrpc\":\"2.0\",\"method\":\"${METHOD}\",\"params\":${PARAMS},\"id\":1}" \
  "${RPC_URL}"
EOF
chmod +x rpc.sh

Use it like this:

./rpc.sh http://127.0.0.1:9944 system_health | jq .
./rpc.sh http://127.0.0.1:9944 rpc_methods | jq -r '.result.methods[]'

Create a height monitor that compares your node with the public Preview RPC endpoint:

cat > monitor-height.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

LOCAL_RPC="${LOCAL_RPC:-http://127.0.0.1:9944}"
REMOTE_RPC="${REMOTE_RPC:-https://rpc.preview.midnight.network}"
INTERVAL_SECONDS="${INTERVAL_SECONDS:-30}"

rpc_block_number() {
  local url="$1"
  local hex_number
  hex_number=$(curl -fsS \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"chain_getBlock","params":[],"id":1}' \
    "$url" | jq -r '.result.block.header.number // empty')

  if [ -z "$hex_number" ]; then
    printf '0\n'
    return
  fi

  printf '%d\n' "$((hex_number))"
}

while true; do
  local_height=$(rpc_block_number "$LOCAL_RPC")
  remote_height=$(rpc_block_number "$REMOTE_RPC")
  timestamp=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

  if [ "$local_height" -eq 0 ] || [ "$remote_height" -eq 0 ]; then
    printf '%s local=%s remote=%s lag=unknown\n' \
      "$timestamp" "$local_height" "$remote_height"
  else
    lag=$((remote_height - local_height))
    printf '%s local=%s remote=%s lag=%s\n' \
      "$timestamp" "$local_height" "$remote_height" "$lag"
  fi

  sleep "$INTERVAL_SECONDS"
done
EOF
chmod +x monitor-height.sh

Run it:

LOCAL_RPC=http://127.0.0.1:9944 \
REMOTE_RPC=https://rpc.preview.midnight.network \
INTERVAL_SECONDS=30 \
./monitor-height.sh

A healthy node shows increasing local height and a shrinking lag. A synced node stays close to the remote height and keeps peers.

Monitor peer connectivity

Start with the RPC view:

./rpc.sh http://127.0.0.1:9944 system_health | jq '.result'

Interpret the fields like this:

Field	Healthy value	What it means
`peers`	Greater than `0`	The node has live P2P connections
`isSyncing`	`true` during catch-up, then `false`	The node still imports historical blocks
`shouldHavePeers`	Usually `true`	The node expects to participate in P2P

Check that the P2P port listens on the host:

ss -ltnp | grep ':30333' || true

Allow inbound P2P traffic if you use ufw:

sudo ufw allow 30333/tcp
sudo ufw status verbose

Check outbound reachability to a boot node:

nc -vz bootnode-1.preview.midnight.network 30333
nc -vz bootnode-2.preview.midnight.network 30333

Check recent peer-related logs:

docker logs --since 15m midnight-full-node \
  | grep -Ei 'peer|bootnode|disconnect|dial|sync|import' \
  || true

Check Prometheus metrics if enabled:

curl -fsS http://127.0.0.1:9615/metrics \
  | grep -Ei 'peer|height|sync|block' \
  | head -n 50

Troubleshoot a node stuck on block 1

A node stuck on block 1 usually has a configuration, dependency, or P2P problem. Work through the checks in order.

1. Confirm the image and network match

Print the active values:

set -a
. ./midnight.env
. ./postgres.env
set +a

printf 'network=%s\n' "$MIDNIGHT_NETWORK"
printf 'image=%s\n' "$MIDNIGHT_NODE_IMAGE"
printf 'cardano_network=%s\n' "$CARDANO_NETWORK"

For Preview, use MIDNIGHT_NETWORK=preview, CARDANO_NETWORK=preview, and a Preview-compatible image. For Preprod, all three values must point to Preprod. Do not run a Preview image against Preprod boot nodes or a Preprod Cardano-db-sync database.

2. Confirm the chain spec exists inside the image

docker run --rm \
  --entrypoint test \
  "${MIDNIGHT_NODE_IMAGE}" \
  -f "/res/${MIDNIGHT_NETWORK}/chain-spec-raw.json"

No output means the file exists. Any nonzero exit means the image or network is wrong.

3. Confirm Cardano-db-sync is caught up

docker logs --tail 100 cardano-db-sync

Then rerun the sync percentage query from the setup section. If Cardano-db-sync is far behind, let it finish. The Midnight Docker repository documents a related error that appears when the Cardano node or db-sync is not ready:

Unable to author block in slot. Failure creating inherent data provider:
'No latest block on chain.' not found.
Possible causes: main chain follower configuration error, db-sync not synced fully,
or data not set on the main chain.

For a full node, the practical response is the same: check the Cardano services, database connection string, and network selection before resetting the Midnight data volume.

4. Check the PostgreSQL connection string from inside the node network

Run a temporary PostgreSQL client on the same Docker network:

docker run --rm \
  --network midnight-node-net \
  -e PGPASSWORD="${POSTGRES_PASSWORD}" \
  postgres:15.3 \
  psql \
    -h postgres \
    -p 5432 \
    -U "${POSTGRES_USER}" \
    -d "${POSTGRES_DB}" \
    -c 'SELECT COUNT(*) FROM block;'

If this fails, fix PostgreSQL before you touch the Midnight node.

5. Check peers and boot nodes

./rpc.sh http://127.0.0.1:9944 system_health | jq .

If peers is 0, check firewall rules, cloud security groups, outbound access, and boot node values. If peers appear and disappear repeatedly, check system time, network stability, and image or chain spec mismatch.

Check clock sync:

timedatectl status

Enable NTP if needed:

sudo timedatectl set-ntp true

6. Check for memory pressure or OOM kills

docker inspect midnight-full-node \
  --format 'OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}} RestartCount={{.RestartCount}}'

dmesg -T | grep -Ei 'out of memory|oom|killed process' | tail -n 20 || true

If the node or PostgreSQL is OOM-killed, add RAM before restarting. Repeated OOM events can corrupt local state or keep the node in a restart loop.

7. Reset only the data that needs resetting

Reset the Midnight node data if you changed the Midnight network, changed from full to archive mode, used the wrong chain spec, or hit a corrupted Midnight database.

docker rm -f midnight-full-node || true
docker volume rm midnight-node-data || true
docker volume create midnight-node-data

Do not delete the PostgreSQL or Cardano-db-sync volumes unless you changed the Cardano network, damaged the database, or intentionally want a full resync.

If you must reset Cardano-db-sync too, stop services and identify the exact volume names before removal:

docker compose \
  --env-file postgres.env \
  --env-file midnight.env \
  -f cardano-db-sync.compose.yml \
  down

docker volume ls --format '{{.Name}}' \
  | grep -E 'cardano|db-sync|postgres'

Remove only the volumes that belong to this node directory and this Compose project. Your Compose project name may differ by host, so do not paste a volume deletion command from another machine into production.

Verify that the node is synced and healthy

Use this checklist after initial sync and after every restart:

Containers are running.

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

The health endpoint responds.

curl -fsS http://127.0.0.1:9944/health

The node has peers.

./rpc.sh http://127.0.0.1:9944 system_health | jq '.result.peers'

The block height increases.

for _ in 1 2 3; do
  ./rpc.sh http://127.0.0.1:9944 chain_getBlock \
    | jq -r '.result.block.header.number'
  sleep 12
done

Midnight's documented block time is 6 seconds, so a healthy node near the tip should observe new blocks over short intervals. Network conditions can vary, so use repeated checks instead of a single sample.

The local height is near the public RPC height for the same environment.

LOCAL_RPC=http://127.0.0.1:9944 \
REMOTE_RPC=https://rpc.preview.midnight.network \
INTERVAL_SECONDS=10 \
timeout 35 ./monitor-height.sh

Prometheus responds.

curl -fsS http://127.0.0.1:9615/metrics > /tmp/midnight-metrics.txt
wc -l /tmp/midnight-metrics.txt

Logs show normal operation, not repeated disconnects, database errors, or panics.

docker logs --since 30m midnight-full-node \
  | grep -Ei 'error|warn|panic|disconnect|database|db-sync' \
  || true

A healthy node has a running container, a responsive local RPC endpoint, nonzero peers, increasing block height, low height lag, and no repeated fatal log lines.

Maintain the node

Check the compatibility matrix before every upgrade. Stop the node, pull the new image, and restart with the same network and data volume only when the release notes allow that upgrade path.

docker rm -f midnight-full-node

docker pull "${MIDNIGHT_NODE_IMAGE}"

# Re-run the docker run command from the setup section with the new pinned image.

Back up configuration files, not just volumes:

tar -czf "midnight-node-config-$(date -u +%Y%m%dT%H%M%SZ).tar.gz" \
  midnight.env \
  postgres.env \
  cardano-db-sync.compose.yml \
  rpc.sh \
  monitor-height.sh

Keep these files out of public repositories. postgres.env contains credentials.

Next steps

After the node is stable, connect local tooling to http://127.0.0.1:9944, import the Midnight Insomnia collection if you prefer a GUI client, and add external monitoring for container restarts, peer count, height lag, disk use, and PostgreSQL health.

For DApp development, pair the node with the Midnight indexer, wallet tooling, and a proof server. For production operation, keep RPC private, monitor disk growth, and rehearse upgrades on Preview or Preprod before touching Mainnet.

References

Affiliates on Autopilot with CREEM's AffiliateHub

Arihant Agarwal — Tue, 31 Mar 2026 23:34:13 +0000

Most affiliate setups require you to bolt a third-party tool onto your payment processor, wrangle a webhook integration, and maintain two separate billing systems every time you update your pricing. Creem eliminates all of that. Because Creem is your Merchant of Record — meaning it already processes every sale, handles tax compliance, and records every transaction — adding an affiliate program is a configuration step, not an engineering project.

The result is attribution that never breaks (because the tracking is inside the same system that records the sale), payouts that actually move money to partners internationally, and a dashboard that shows you exactly which affiliates are driving revenue. This guide walks through the entire setup from scratch.

How Creem's Affiliate Platform Is Structured

Your affiliates never touch your Creem dashboard. They get a purpose-built portal under a separate subdomain, with their own login. This matters because it means you never have to manage permissions, roles, or the awkward moment where a partner accidentally sees your revenue numbers.

Step 1 — Create Your Affiliate Program

In your Creem dashboard, navigate to Growth → Affiliate Hub in the left sidebar. If this is your first program, you'll land on the creation wizard. If you've been here before, click New Program.

Fill in the four fields that define your program:

1 Program Name. What your affiliates will see when they join. Use your product name — something they'll recognise, not an internal codename.

2 Website URL. Where referral links send visitors. This should be your public-facing landing page or homepage — not your app login, not your dashboard. This is the most common setup mistake and it kills your conversion rate before it has a chance to breathe.

3 Program Slug. The URL identifier appended to every affiliate link. If your slug is my-saas, referral links read as yoursite.com?ref=my-saas-[partnercode]. Keep it lowercase, hyphen-separated, no special characters.

4 Commission Rate. The percentage of each sale paid to the affiliate. For SaaS products, the range that meaningfully motivates promotion is typically 20–40%. Below 10% is rarely worth an affiliate's effort. Above 50% works only if your margins support it.

Once you save, your Affiliate Hub dashboard appears. The program is live, the commission structure is set, and Creem is ready to track referrals. Nothing to integrate, nothing to configure externally.

Step 2 — Invite Your First Affiliates

From the Affiliate Hub, click Invite Partner. A modal appears asking for two things: your partner's name and email address. Enter both and click Send Invite.

Creem sends your partner an email with a join link. In your Partners list, they immediately appear with an Invited status badge. Once they accept, their badge flips to Active and they appear in your analytics.

By default, programs are invite-only. Anyone you haven't explicitly invited cannot join. If you want an open program where potential partners can self-enroll, toggle Public Program in your program settings. For most SaaS founders, invite-only is the right default — it keeps your affiliate roster deliberate and manageable.

Step 3 — Configure Per-Affiliate Settings

Click any affiliate in your Partners list to open their detail panel. This is where Creem's affiliate management goes from simple to genuinely powerful.

*Custom commission rates
*
Every affiliate inherits your program's default commission rate — but you can override it per-partner. A newsletter writer with 50,000 subscribers who drives consistent volume deserves a different rate than a new partner you're still evaluating. You can set individual rates anywhere from 0 to 95%, independent of the program default, without affecting anyone else.

*Product restrictions
*
If you sell multiple products, you can restrict which ones a given affiliate is authorised to promote. Leave this blank and they can link to anything. Specify products and only those links earn commission. This is essential if you have a flagship product you want to protect from off-brand promotion, or a legacy product you'd prefer not to amplify.

Step 4 — What Your Affiliates See

When a partner accepts their invitation, they land at affiliates.creem.io and sign in with Google or a magic link — using the same email you invited. First-time users complete a brief profile: display name, bio, website, and optional social links. This is what you see when reviewing partners, so encourage them to fill it out properly. A blank profile is a lost first impression.

Their dashboard surface three things immediately:

1 Referral link. Their unique URL, one-click to copy, displayed at the top of the dashboard. This is what they share everywhere.

2 Performance metrics. Revenue, customers referred, total clicks, and conversion rate — all updating in real time as sales happen.

3 30-day earnings chart. A visual breakdown of commission earned each day. This is the chart that turns passive affiliates into active ones — seeing a spike after a promotion is motivating in a way that a static number is not.

How tracking works

When a visitor clicks an affiliate's referral link, Creem sets a tracking cookie in their browser. Any purchase completed within the cookie duration window is automatically attributed to that affiliate and logged against their commission balance. No manual step is required on either side.

*Creating affiliate-specific discount codes
*
In your Creem dashboard, navigate to Products → Discount Codes and create a new code. Name it after your affiliate — their handle or brand makes it memorable and self-attributing. Set your discount amount, activate the code, and share it alongside their referral link. You now have two independent signals tracking the same customer. Belt and suspenders.

Step 5 — Track Performance in the Affiliate Hub

Your Affiliate Hub is the control room. At the top, six headline metrics give you an instant program health check:

Step 6 — Understand the Payout Flow

Affiliates request payouts from the Balance page inside their portal. Three balance states are shown:

Before an affiliate can request their first payout, two things must happen. First, they complete identity verification (KYC) through Sumsub — a government-issued ID and selfie, typically approved within 24 hours. Second, they add a payout method: bank transfer via Paysway, or USDC cryptocurrency via Mural. International affiliates particularly appreciate the crypto option, which eliminates the wire transfer friction that kills payouts to non-US partners.

Pro Founder Tip: In your program settings, you can set a minimum payout threshold — the balance an affiliate must reach before they can request a withdrawal. This reduces payment processing overhead and simplifies your month-end accounting. A $50 or $100 minimum is common and rarely causes friction with active affiliates who are earning regularly.

You're Live

At this point you have a fully operational affiliate program: a commission structure set, partners invited, referral links generated, discount codes paired as backup attribution, and a payout flow that handles identity verification and international transfers automatically.

The last question is where to find affiliates worth inviting. The fastest answer is your existing user base — specifically anyone who has already mentioned your product publicly in a review, tweet, or blog post. They believe in the product and have an audience. You're adding a financial incentive to something they're already doing.

Beyond users: complementary tool founders (different product, same audience) make excellent affiliate partners because the cross-promotion is genuinely useful to both sides. One well-placed partnership outperforms fifty cold outreach attempts every time.

When you do invite someone, don't send them just the referral link. Send them a short explainer of what converts, a sample caption or tweet they can remix, and your best-performing screenshot or demo. The easier you make it to promote you, the more they actually will. The link alone sits in a folder. A toolkit gets used.

DEV Community: Arihant Agarwal

Security Checklist for Midnight dApps Before Deployment

Prerequisites

Required reading

Start with a clean verification gate

Understand the security boundary

1. Audit every disclose() call

2. Review ownPublicKey() usage

3. Verify replay protection with nonces or nullifiers

4. Review exported ledger fields

5. Verify witness implementation correctness

6. Confirm version compatibility

7. Test proof generation on Testnet or a local network

CI checklist

Troubleshooting

The compiler reports a missing disclosure

ownPublicKey() appears in authorization

A replay test succeeds twice

A sealed field fails compilation

Proof generation fails but unit tests pass

Port 6300 is unavailable

Deployment decision

Next steps

Midnight vs Other Privacy Chains: Architecture Comparison for Developers

Prerequisites

What this comparison checks

A current Midnight baseline

Midnight: Compact, Kachina, Zswap, and the dual ledger

Aztec: Noir, Aztec.nr, PXE, and notes

Aleo: Leo, records, transitions, and mappings

Mina: o1js, zkApps, and recursive proofs

Zcash Sapling: shielded payments, not general DApps

Developer experience comparison

How to choose

Troubleshooting common mistakes

References

Getting NIGHT Tokens: Exchanges, Bridging & Wallet Funding on Mainnet: An Overview

Prerequisites

Understand NIGHT and DUST

Where to get NIGHT

Option 1: Buy NIGHT on a centralized exchange

Option 2: Swap for NIGHT on Cardano

Option 3: Redeem previously claimed NIGHT

Choose the right wallet

Set up a Midnight wallet in Lace

Withdraw NIGHT from an exchange

Step 1: Confirm the withdrawal network

Step 2: Copy a Cardano receiving address

Step 3: Send a small test withdrawal

Step 4: Withdraw the remaining balance

Step 5: Prepare for Midnight usage

Understand designation

Understand the Cardano-to-Midnight bridge

What does not exist yet

Direct Cardano or exchange transfers to a Midnight wallet are not the default

DUST is not a market token

Wallet support is not uniform

Bridge UX is still evolving

What is coming

Troubleshooting

The exchange lists NIGHT, but withdrawals are disabled

NIGHT does not appear in my wallet

I have NIGHT, but I cannot transact on Midnight

I copied the wrong address type

I want to use Midnight without buying NIGHT

Security checklist

Next steps

Related resources

Running a Midnight Node: Setup, Sync & Monitoring: An In-depth Tutorial

What you will build

How Midnight full nodes fit into the network

Prerequisites

Choose the network and image version

Size the host

Install system packages

Create the working directory

Start Cardano-db-sync

Pull and inspect the Midnight node image

Start the Midnight full node

Run an archive node instead

1. Audit every `disclose()` call

2. Review `ownPublicKey()` usage

`ownPublicKey()` appears in authorization

Port `6300` is unavailable