Differences between Brevis and Glyph

The simplest way to understand the difference

Brevis = “Onchain History Coprocessor”

Brevis helps smart contracts answer questions like:

  • Did this wallet do X in the past?

  • What is the user’s historical volume / transactions / balances?

  • Compute something from receipts and verify it on-chain.

Brevis is a ZK compute layer for historical chain data.

Glyph = “User Coprocessor”

Glyph helps applications answer questions like:

  • Is this a real unique user (under a chosen policy)?

  • Are these wallets the same user (with consent)?

  • What kind of user is this (intent/persona) without leaking their full history?

  • Can we personalize access, rewards, pricing, or onboarding based on verifiable user claims?

Glyph is a User + Consent + Reputation compute layer.

Brevis proves facts about transactions.

Glyph proves facts about people (as users) behind multiple wallets.


What problem each infrastructure is designed to solve

Brevis solves: “Smart contracts can’t read the past efficiently”

Smart contracts are expensive and constrained. Computing on-chain over long periods or many transactions becomes infeasible at scale.

Brevis enables a model where:

  • historical data is fetched + computed off-chain,

  • a ZK proof is generated,

  • the result is verified on-chain,

  • the contract executes logic from a trusted output.

This unlocks “data-driven” smart contract logic.


Glyph solves: “Web3 still can’t talk to users”

Web3 has wallets, not users.

That breaks everything that modern apps depend on:

  • growth targeting

  • retention systems

  • loyalty tiers

  • sybil-resistant rewards

  • fair airdrops

  • trust gating

  • personalization

  • cross-chain continuity

Glyph introduces a missing primitive:

A privacy-preserving, consented, cross-chain user layer

so apps can finally reason about users the way Web2 does — without centralization, without doxxing, without raw data extraction.


Same infrastructure skeleton, different payload

Brevis and Glyph share a similar infrastructure pattern:

(1) Data → (2) Compute → (3) Proof → (4) Verify → (5) Use

But what they compute and what they return is fundamentally different.

Brevis returns: computed outcomes from chain history

Example outputs:

  • “User swapped ≥ $500 in the last 30 days”

  • “User qualifies for a reward”

  • “User’s average balance was X”

These are transaction-derived facts.

Glyph returns: portable user claims

Example outputs:

  • “This is a Unique User under Policy v2”

  • “These 4 wallets belong to the same person (consented proof)”

  • “User is Tier-3 loyal based on 30-day activity”

  • “User is a high-intent LP, not a short-term farmer”

  • “User is a returning gamer with stable engagement behavior”

These are identity + intent + reputation assertions that can be reused across apps.


What developers integrate: compute vs policies

Brevis integration mindset: “Write a computation”

Developers define a data query + circuit that computes some condition from chain history.

Glyph integration mindset: “Pick a policy”

Developers choose standardized policies like:

  • WalletLinkConsent_v1

  • UniqueUser_v2

  • LoyaltyTier_30d_v1

  • DeFiIntentScore_v1

  • ChurnRiskSignal_v1

Instead of every app inventing their own scoring system, uniqueness filter, and wallet mapping logic, Glyph offers a portable policy layer.

This is the big shift.

Brevis makes smart contracts smarter.

Glyph makes apps user-aware.

Last updated