Minokawa Community Call - 2026/09/23

Summary of Technological Concepts & Decisions (Minokawa Community Call)

Release Planning / Branch Management

• The group discussed release readiness and timing:
  • Waiting approximately 24 hours, targeting Thursday.
• References checks were noted for:
  • Curve25519 / ED25519
  • “dynamic dispatch” status being close to ready
• They also covered whether to use a new release process and how to coordinate via mailing lists.

Midnight / Compact: Dynamic Dispatch for Cross-Contract “Type Calls”

Jonathan introduced a problem involving cross-contract calls that use:

• Contract types
• Contract schemas

Behavior in the prior (end of June) release

• The system allowed specifying:
  • Contract type T
  • Schema C(number) (example)
• However, the executed code for schema C was effectively tied to the type.
  • Result: a single code version per type T
• This makes behavior less aligned with typical object-oriented / dynamic dispatch expectations, where:
  • different contract values should lead to different implementation code.

Proposed fix: value-based dynamic dispatch (“COEP” being discussed)

The new capability is intended to relax the old limitation:

• Instead of one code version per type, the system supports:
  • different code per concrete value of type T
• This means the executed schema implementation depends on the specific contract value (V) passed in.

Security / Correctness Constraints (ZK Verifier Compatibility)

Participants emphasized that executable code cannot be arbitrary:

• If the provided code does not match what’s deployed on-chain:
  • the verifier key would not match
  • therefore the required ZK proof could not be generated/validated
• Dynamic resolution must therefore ensure the loaded module corresponds exactly to the deployed contract.

Rejected Design: On-Chain / System Contract-Code Registry

They considered a registry mechanism such as:

• “Given a contract address, the chain provides deployed contract code for execution.”

This approach was rejected for two main reasons:

1. There is no standardized compiled-contract representation beyond JavaScript.
   • Retrieving code would require executing JS provided by others.
   • This raises trust/isolation risks.
2. Since private state cross-calls are not fully handled yet:
   • strong isolation would be required
   • they did not want a placeholder mechanism that might later conflict with the eventual private-state isolation model.

Adopted Approach: DAPP-Controlled Address → Code Resolution via a Provider

Instead of system-wide code loading, the mechanism allows the DAPP to decide how to resolve contract addresses into code.

Key components

• A TypeScript/JavaScript module type representing “loaded compiled contract code”
• A contract module provider abstraction with a single required method:
  • resolve(address) -> module (promise)
  • It returns the appropriate module/code for that contract address.

Mentioned provider examples

• A static provider backed by a map: address → import/module
• A more dynamic provider that uses:
  • a lookup engine/registry (quality-control/testing implementations were referenced)

Error Handling and Mismatch Detection

The new system introduces distinct error categories, including:

• Wrong/old compiler output
  • module doesn’t match the expected module format
• Provider lookup errors
  • resolution not performed properly
• Verifier key mismatch
  • loaded code does not match the deployed contract’s expected verification key
• Implementation mismatch
  • loaded module lacks the expected verifier key expectations

They also discussed dynamic validation needs:

• Even if schemas “type-check” in TS, runtime guarantees may still require dynamic checks:
  • argument/return arity and types may only be validated dynamically in JS-like environments
• Planned for the next Compact release:
  • dynamic validation with helpful errors

Relation to Ethereum-Like Patterns (DEX-Style Design)

The speaker argued this pushes Compact toward Ethereum interface/dispatch-like patterns:

• call by interface (contract type/schema)
• but allow behavior to differ per concrete implementation (concrete contract values)

Backend / Language Questions (TypeScript, Compact, ZKIR, Cross-Platform)

Discussion clarified separation between:

• Compact language syntax vs
• semantics changes introduced by newer compilers

Key points:

• Compact syntax doesn’t change, but generated semantics do for newer compiler versions.
• Other backends (e.g., Rust conceptually) would need to implement the same cross-value code resolution logic.

ZKIR / Zero-Knowledge Proof Composition

Questions addressed how cross-contract proof challenges compose:

• It was described as composition of two proofs:
  1. one for the called contract
  2. one for the caller interaction
• This uses existing “communication commitment / obligations” concepts.

There was also a brief mention of potential register linkage changes (Register 8 → 9), though details were not fully confirmed.

Conditional Logic & Failure Handling in Zero-Knowledge Proofs

Participants discussed whether a cross-contract call result could be used like:

• true/false conditional logic in Compact/ZKIR

Clarifications:

• In ZK circuits, branch “execution” differs from imperative JS runtime behavior.
• Non-chosen branches are handled in a way compatible with ZK proof semantics.
• There is no try/catch-like recovery:
  • if a proof scheme/assert fails, the overall proof/transaction fails.

Key takeaway: runtime “detect and continue” behavior isn’t supported; failures surface at proof/transaction application time rather than being safely caught.

Document / Spec Process: COEP Numbering

The group discussed upgrading a specification from draft/design to a numbered COEP (e.g., COEP #4 suggested).

They agreed to:

• assign a number for iteration/discussion
• keep status as draft/open until proper review and acceptance
• ensure the document accurately matches what was implemented
  • avoid approving a spec that describes something different

---

Main Speakers / Sources

• Jonathan (primary presenter on the dynamic dispatch/type-call problem and the COEP/spec description)
• Joe (implementation details; TS/module-provider specifics; ZKIR composition concepts)
• Kevin (process/release/spec coordination; involved in COEP numbering)
• Kent and Ron (attending/mentioned during release and mailing-list/process discussion)
• Andre, William, Jameson, Yuri, Ken, Matthew (other participants; comments and testing work mentioned)