Brew

Brew is a conditional trust-release app for agentic systems. It is designed for cases where someone wants to commit funds now, but only release them later if the right real-world condition is actually proven.

Example use cases include a university scholarship that unlocks only after a degree is verified, a DAO grant that pays out after a milestone is completed, a fellowship stipend that releases after participation is confirmed, or a workplace reward that unlocks after employment or contribution is attested. In all of these scenarios, the core problem is the same: a promise should be made today, but the money should only move after the condition has had time to “brew” into something verifiable.

In Brew, a sponsor creates a trust by locking ERC-20 funds in escrow, selecting a beneficiary, choosing a proof template, and setting a refund deadline. The template is not just metadata, but it defines what kind of proof is acceptable, which attestation schema is expected, and what timing rules apply to that proof.

Once the trust is created, the beneficiary submits proof through an attestation. Brew then evaluates whether the condition is satisfied, but without letting AI directly control money. That distinction is the main point of the project. AI can help interpret evidence, but the actual release path should still be explicit, inspectable, and trustworthy. In Brew, the review process produces a signed receipt, the reasoning artifact remains visible, and the final release only happens if the contract-level checks all pass.

From the user’s perspective, Brew turns a vague “AI said yes” workflow into something much more structured. The sponsor can see what proof is expected before creating a trust, and later the beneficiary can show the proof, trigger review, inspect the result, and confirm the final release. The product is meant to make agentic financial workflows feel safer, more legible, and easier to trust.

In short, Brew is our answer to conditional trust in agentic systems: a product where promises can be committed early, reviewed carefully, and released only through a transparent and enforceable path.

Brew is built as a multi-layer release system that separates proof review from release authority. The app itself is a Next.js web interface that lets sponsors create trusts and lets beneficiaries submit proof, inspect review artifacts, and trigger release. The actual escrow and verifier contracts are deployed on Base Sepolia, which is why the app uses Base Sepolia as its wallet network. ERC-20 funds are locked in escrow first, and the final release is enforced by onchain contracts rather than by the frontend or by an AI model.

For proof, we use EAS attestations. Each trust references a registered template, and each template is tied to a schema plus timing rules such as freshness and expiry windows. That means the proof layer is structured rather than arbitrary. The verifier checks not only that an attestation exists, but also that its schema matches the selected template, that the recipient matches the beneficiary, that the attestation is still fresh, and that the signed review receipt is valid. In a production-style flow, issuer permissions can also be restricted per template, so having the right schema alone is not enough.

For the agentic review layer, we use 0G in three ways. First, 0G Compute runs a role-based review council made up of Evidence, Policy, and Risk reviewers. Instead of using one opaque model output, we split review responsibility across multiple roles so the same trust context is checked from different perspectives. Second, 0G Storage is used to persist the full review bundle, which makes the review path inspectable rather than hidden in a backend log. Third, 0G Agentic ID is used to represent the reviewer identities so the review roles are explicit and attributable.

KeeperHub is used as the execution workflow layer. One important architectural detail is that the receipt-service, not KeeperHub itself, runs the long-running 0G review and storage steps. We made that choice because the workflow environment can be restrictive for direct external compute-network fetches, so the receipt-service handles 0G Compute, 0G Storage uploads, and EIP-712 signing first. Once the review result is ready, it sends the signed release payload into KeeperHub, and KeeperHub performs the final web3 action by calling the verifier contract. This was one of the more hacky but useful parts of the build, because it let us keep KeeperHub in the critical execution path while still making the 0G review flow reliable.

We also use The Graph to index trusts, templates, review receipts, releases, and refunds so the UI can reflect the current workflow state without relying on the frontend as the source of truth. The receipt-service is deployed separately on Railway, while the web app is designed as the user-facing layer only. This separation keeps signing keys, 0G secrets, storage credentials, and KeeperHub webhook secrets out of the frontend.

Overall, the project is built around one deliberate design principle: AI can check whether a condition looks satisfied, but AI should not directly move money. 0G helps us make the review process agentic and inspectable, KeeperHub gives us a durable execution workflow, and the contracts keep final release authority onchain.