The problem BlockByBlock solves

Block by Block is a decentralized peer-to-peer donation platform that lets donors send money directly to verified recipients on-chain, in USDT, with zero intermediary custody and zero platform fees.

The core problem it solves: in traditional charity/donation flows, money passes through an organization that holds funds, decides how they're used, and takes a cut — donors can't verify their money reached the actual cause, and there's a trust gap between giving and impact. Block by Block removes the intermediary in two ways:

1. No custodial middleman for funds — donations move directly from donor wallet to a smart contract (CauseVault), and recipients withdraw directly. Neither the backend nor the platform ever holds or signs transactions on behalf of users.
2. An autonomous AI agent replaces manual/institutional vetting — and acts as its ow a human review board, an AI agent (DeepSeek v4.1 Flash via OpenRouter) evaluates theevidence a recipient uploads for a cause and, if it passes a confidence threshold (0.80), the agent signs and submits the verification transaction itself, calling verifyCause on the CauseVault contract with its own private key. This function is restricted by an onlyAgent most an advisor whose opinion someone else acts on — it's a distinct on-chain identitywhose judgment becomes a binding, irreversible state change. Only causes it verifies this way can receive donations or allow withdrawals.

This makes the AI agent the single deliberate exception to the platform's core rule that "the backend never signs on behalf of users" — the backend still never touches donor or recipient funds, but the AI agent has genuine signing authority over the verification step, making trust n dependent on an institution's word.
Concretely, the flow is: a recipient signs up, links a wallet, creates a cause with agent reviews it and, if approved, verifies it on-chain with its own signature → thecause becomes publicly explorable → donors browse verified causes and donate USDT directly through their own wallet signature → recipients withdraw collected funds, again signing directly with their wallet. Every state transition is anchored on HSK Chain testnet, so it's auditable r

It's a hackathon project (Ethereum Builders Tour Cali) built with a Solidity/Foundryckend that only orchestrates, a Python AI verification agent, and a Next.js frontend.

Challenges we ran into

Smart contracts. This was my first real exposure to Solidity and on-chain development, so the learning curve was steep from day one. Beyond just writing CauseVault.sol, understanding concepts like access control modifiers (onlyAgent, onlyOwner), the two-step ERC-20 flow (approve before donate), and how state changes like withdrawFunds resetting collected to zero affect historical data took real trial and error. Debugging with Foundry (forge test, forge coverage) was unfamiliar territory, and reasoning about irreversible, publicly-visible state changes felt very different from writing regular backend code where you can just patch a bug and redeploy.

AI agent integration. Wiring the AI agent into the verification flow was harder than expected because it isn't just an API call — it's an autonomous on-chain actor. I had to understand how the agent evaluates evidence via OpenRouter, applies a confidence threshold, and then signs and submits its own transaction (verifyCause) with its own private key. Getting the OpenRouter integration right also took some trial and error (the /completions vs /messages endpoint format mismatch coinating the off-chain AI decision with the on-chain confirmation — while keeping thebackend from ever touching signing — required rethinking how "verification" works compared to a normal review workflow.
Understanding testnet and gas. This was probably the most conceptually unfamiliar part. Grasping that every transaction — even a "test" one — costs real (testnet) gas, that you need a faucet to get funds before you can do anything, and that RPC nodes can lag behind the actual chain can succeed on-chain before your app "sees" it) was a mental model I had to buildfrom scratch. It also affected how the app itself had to be designed: since the backend can't just assume a transaction succeeded, the frontend has to sign, then retry confirmation against the chain, rather than trusting a single request/response like a normal REST API.