skills.rest
devrelaicom
devrelaicomOFFICIAL
Explore all skills by this author →
GitHub

core-concepts:architecture

Explain Midnight transaction anatomy with Zswap offers, contract calls, and cryptographic binding.

37|9|Updated Feb 25, 2026
Search Tags:#transactions#state-management#zk#compact#midnight#zswap#cryptographic-binding
One-click install
npx skills add https://github.com/devrelaicom/midnight-expert --skill core-concepts-architecture
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: core-concepts:architecture
Source: https://github.com/devrelaicom/midnight-expert/tree/main/plugins/core-concepts/skills/architecture
Command: npx skills add https://github.com/devrelaicom/midnight-expert --skill core-concepts-architecture

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Developers, auditors, and protocol designers need a concise, authoritative explanation of how Midnight composes Zswap token operations, Compact contract execution, and cryptographic binding into atomic, privacy-preserving transactions. This Skill clarifies transaction anatomy, the guaranteed vs fallible execution model, ledger state shape, and the cryptographic guarantees that prevent value injection, double-spend, and proof reuse.

Core Features & Use Cases

  • Transaction Anatomy: Explains guaranteed and fallible sections, Zswap offers, contract call transcripts, binding randomness, and fee handling.
  • Cryptographic Binding: Details Pedersen commitments, Schnorr segment bindings, ZK-SNARK composition, and why proofs cannot be reused across transactions.
  • State & Ledger: Describes the commitment Merkle tree, nullifier set, recent Merkle roots window, contract state storage, and verification key management.
  • Practical Patterns: Guidance for simple transfers, contract interactions, atomic swaps, and merging offers off-chain with validation rules.
  • Use Case: When building a Compact contract that accepts shielded tokens and must remain balance-safe across merged transactions, use this Skill to ensure correct transcript construction, proof binding, and state updates.

Quick Start

Explain the Midnight transaction anatomy, focusing on guaranteed vs fallible sections, Pedersen-based binding, and the verification order needed to safely build a contract that accepts shielded token inputs.

Frequently Asked Questions about core-concepts:architecture

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How does a Midnight transaction combine Zswap offers and Compact contract calls?▼

A Midnight transaction combines Zswap offers and Compact contract calls by structuring them into guaranteed and fallible sections with binding randomness, ensuring atomic execution. This architecture allows shielded token operations and contract logic to execute together or fail together safely.

What is the difference between guaranteed and fallible execution sections in Midnight?▼

Guaranteed execution sections in Midnight transactions always succeed and handle critical operations like fee handling and cryptographic binding, while fallible sections contain contract call transcripts that may fail. This separation ensures that even if contract execution fails, the ledger invariants and balance safety are preserved.

How do I build a Compact contract that accepts shielded tokens safely?▼

To build a balance-safe Compact contract for shielded tokens, construct correct transaction transcripts with Pedersen commitment-based balance checks and proper state updates. Follow Midnight's defined verification and execution order to ensure nullifier and commitment ledger invariants are maintained across merged transactions.

Can I merge multiple Zswap offers off-chain before submitting a Midnight transaction?▼

Yes, Zswap offers can be merged off-chain using validation rules before submission to the Midnight network. This pattern supports atomic swaps and privacy-preserving transaction flows, but merged offers must still satisfy Pedersen commitment balance checks and Schnorr segment binding to ensure cryptographic integrity.

Why does Midnight use a nullifier set and commitment Merkle tree for transaction state?▼

Midnight uses a commitment Merkle tree to store shielded value commitments and a nullifier set to prevent double-spending, backed by a recent Merkle roots window for validation. Together with ZK-SNARK proof composition and verification key management, these structures enforce ledger state invariants and prevent proof reuse.

Related Skills

Explore More Software Engineering Skills→
devrelaicomdevrelaicom
37

core-concepts:protocols

Explain Midnight's Kachina and Zswap protocols for private smart contracts and shielded token transfers.

Official
Advanced
devrelaicomdevrelaicom
37

core-concepts:data-models

Compare UTXO and account token models for Midnight ledger design.

Official
Intermediate
aaronbassettaaronbassett

midnight-core-concepts:architecture

Explains Midnight's architecture including Turret, Switchboard, and Ledger components.

Community
Intermediate
mitchuskimitchuski

agentprivacy-nullifier-design

Design nullifier construction, deployment, and verification mechanisms for privacy-preserving invalidation.

Community
Advanced