Skip to main content

Ora ABI v0.1: Tooling-First Interfaces for Smart Contracts

· 3 min read
axe
axe
Creator of Ora

We just published the Ora ABI v0.1 spec.
This is a tooling-first ABI model with stable type identities, a clear manifest format, and optional wire profiles for encoding.

It's the interface layer we wish every smart contract language had: self-describing, structured, and built for codegen, explorers, and UI generation.

Why a New ABI​

Most ABIs are centered around call encoding.
That is necessary, but it's not enough.

We needed an ABI that:

  • preserves type identity across builds,
  • supports rich metadata for UIs and explorers,
  • models refinements and constraints directly,
  • and stays stable as tooling evolves.

So the Ora ABI focuses on the interface model first, and treats wire encoding as a profile you can change without breaking the ABI itself.

Two Layers: Manifest + Wire Profiles​

The ABI is split into two layers:

  1. Manifest — the authoritative interface and type graph.
  2. Wire profiles — optional mappings for encoding (EVM, future VMs, etc).

The manifest is canonical and stable.
Wire profiles can evolve without changing the ABI model.

Wire Profiles: EVM-Default and Beyond​

Wire profiles are where call/return/event encoding lives.
The default profile today is evm-default, which targets Solidity ABI compatibility.

But wire profiles are explicitly extensible:

  • EVM-compatible profiles (Solidity ABI v2, packed, custom selectors)
  • Non-EVM chains with different calling conventions
  • Alternate encodings like protobufs or custom binary schemas

The point is to decouple the interface model from any single encoding.
We can keep a stable, self-describing manifest while adding new wire profiles as the ecosystem expands.

Stable Type Identity​

Types carry a stable ID based on content hashing.
This means: reordering declarations doesn’t change IDs, and tooling can cache safely.

Example:

{
  "typeId": "t:Balance",
  "kind": "refinement",
  "base": "t:u256",
  "predicate": {
    "op": "<=",
    "lhs": { "var": "x" },
    "rhs": { "const": "1000000" }
  },
  "meta": {
    "ui": { "label": "Balance", "min": 0, "max": 1000000, "unit": "wei" }
  }
}

This lets tooling treat a refined type as first-class, instead of throwing constraints away.

ABI Built for Tooling​

The manifest is designed for:

  • code generators,
  • UI builders,
  • explorers,
  • and static analyzers.

It captures:

  • explicit types,
  • callable signatures,
  • metadata and UI hints,
  • stable IDs for caching,
  • and refinement predicates for safety and validation.

This is about reducing custom glue code and making ABI consumers deterministic.

How to Use It​

The canonical file is:

ora.abi.schema.json

The spec defines how to emit it, how to hash it, and how to extend it via profiles.
Compiler-specific details live in the appendix.

Read the Spec​

What's Next​

v0.1 is focused on the manifest and profile declaration mechanism.
Wire formats will evolve as we harden the compiler and tooling.

If you build wallets, explorers, SDKs, or indexers, this ABI is meant for you.
Open an issue or drop feedback — we want this to be a stable foundation for the Ora ecosystem.