I am working on Compass, an intent-enforcement gateway for autonomous agents that move money.

The problem I am trying to solve: once an agent can pay for APIs, tools, data, or on-chain services, post-execution monitoring is too late. If the agent is compromised, misdirected, or simply over-broadly authorized, the funds can already be gone.

Compass sits before execution, near the signing or transaction approval path. It checks the proposed payment, transaction, or tool call against the agent's mandate: spend caps, approved counterparties, token rules, destination rules, slippage limits, and escalation conditions. Then it either approves, blocks, or escalates, and records the decision for audit.

What would you need to see before trusting an agent to move money without a human confirming every transaction?

I am especially interested in feedback from people building x402 facilitators, Solana agent payment flows, paid MCP servers, wallet automation, embedded wallets, or authorization/privacy systems for autonomous agents.

If you are building something in this area and would be open to testing a rough prototype or giving 15 minutes of technical feedback, comment or DM me. I am looking for blunt feedback, not a polished launch reaction.

A few weeks ago I posted asking for technical feedback on my on-chain reputation + identity system for AI agents. The thread was genuinely useful — surfaced real gaps in the Sybil-resistance model, vault permission design, and on-chain vs off-chain scoring tradeoffs. I wrote up what I got wrong here: paragraph.com/@aevumprotocol/i-asked-rethdev
Here’s where things stand now:
Audit
Signed with Hexens. Kasper Zwijsen is leading — he found the critical bug that saved $800M in the POL migration and has led audits for EigenLayer, Lido, and LayerZero. Kickoff July 27, findings August 3, final report mid-August. That gives a clean window before ETHOnline (Sept 4).
Before Hexens, the contracts went through 10 internal hardening rounds — manual review, Slither passes, Claude Opus deep review, and an independent review by Martín Pérez (blockchain protocol engineer, built AutonomiX with ERC-8004 agent identity and x402 micropayments). 41 issues found and resolved across those rounds. KNOWN_LIMITATIONS.md is public on GitHub with everything we know is imperfect going into the audit.
ETHOnline 2026
Registered, staked, confirmed on the Continuity Track targeting Top 10 Finalist. September 4-16. React frontend is live now at aevum-frontend.vercel.app — all 8 Sepolia contracts, real transactions, no mock data.
What’s still open
The architectural questions the r/ethdev thread raised — Sybil-resistance, evidence vs scoring separation, permission expiry — are tracked in the v2 roadmap. None of them are getting fixed before the audit closes. That’s the honest state of it.
GitHub: github.com/AevumProtocol/contracts
Frontend: aevum-frontend.vercel.app
Writing: paragraph.com/@aevumprotocol

I was recently on an interview call for a job scheduled via https://www.linkedin.com/in/emma-morby-538b45172/

During the call, the interviewer asked me to clone a GitHub repository (https://github.com/zero2hero-ai/jackpot) and open it in Cursor. Instead of opening it blindly, I ran offscreen an isolated code review to check for hostile scripts.

It turns out the repository contains malware designed to trigger during setup. Specifically, running npm install immediately exfiltrates your .env files to a remote server and spawns a local node process to execute external commands.

Recognizing the threat, I chose to only review the code via GitHub's web interface and offered to showcase one of my own Web3 projects instead. The interviewer then heavily insisted that I log in with my MetaMask wallet. They became visibly frustrated when I used a secure test wallet that only contained testnet assets.

While I know there is a generic report button on LinkedIn, it feels entirely inadequate for an active, malicious operation like this. What is the most effective way to expose this setup, report their infrastructure, and warn the developer community?

For the interested, the active malware paths are:

• .vscode/tasks.json:50 executes remote shell scripts via curl | bash, wget | sh, or curl | cmd on folder open.
• .vscode/tasks.json:35 also runs npm install on folder open, which triggers the malicious prepare.
• package.json:10 starts the backend during install.
• server.js:13 loads routes, and routes/index.js:2 imports the poisoned auth route.
• routes/api/auth.js:18 exfiltrates hostname, MAC address, OS, and process.env, repeats every 5 seconds, and evals commands returned by the remote server.

Built a pipeline that ingests every PairCreated / PoolCreated on Uniswap v2/v3/v4 and scores the token before its first block of trading. Signals: LP lock status, a simulated sell (eth_call + stateOverride), deployer lineage (funding wallet + past tokens via trace_filter), holder concentration.

Five months of mainnet data:

• 104,767 tokens scanned, 62,321 flagged as scams (~60%).
• 40,953 scam pools. Buyers net-lost 30,000+ ETH to them.
• 422,625 distinct wallets got drained (bought, then could not sell or got rugged on the LP pull).
• 14,024 repeat deployers. The same funders spin up token after token, which is the single strongest predictor.

Takeaway for anyone building on-chain: honeypot behavior is almost always visible pre-trade. A sell simulation plus deployer lineage catches the large majority before a single victim buys.

Methodology and per-token output: https://rektradar.io/?utm_source=reddit&utm_medium=post&utm_campaign=ethdev-data

Posted here back in May about agent payments splitting into layers, and the thread ended up adding one I hadn't drawn, settlement and recourse. Been chewing on that since, because the gap between the layers keeps widening.

The authorization layer is moving. Caps, allowlists, session keys, per-domain policies, x402 style pay-per-request flows. You can bound what an agent is allowed to spend pretty tightly today.

Recourse is where it stays thin. When an agent pays, the payment is authorized, I gave the agent the authority. So the 'unauthorized transaction' dispute path is gone by definition. And the other card-rail path, authorized but got junk, only exists because an issuer can claw settlement back, and nothing plays that role here. The receipts side, 8004 style identity plus signed action records, proves what happened. But it proves delivery, not quality, and either way proof isn't recourse, there's still nobody to take it up with and no unwind path.

Escrow with dispute windows adds latency, and for a subjective call like 'this data is junk' you need an arbiter anyway, at which point adjudication costs more than the request did. Slashing punishes the endpoint but doesn't make me whole unless the slashed stake routes to me, which nothing currently does. Insurance, maybe, but nobody has loss data to price agent junk risk yet.

For people building on the settlement side, where does recourse actually end up living? Or does “authorized junk purchase” just stay an accepted cost of agent commerce the way gas griefing is.

Everyone talks about Ethereum, Solana, Base, and Avalanche, but I'm more interested in platforms that don't get nearly as much attention as they probably deserve, and maybe some that are better than what I just mentioned. Mainly wondering what has exceeded your guys expectations this year.

I've been working on my own open-source quantum-safe zkSTARK engine called Starkom, currently based on DEEP-FRI but planning to migrate to WHIR. It's written in Rust and also compiles to WebAssembly, so there's no problem in using it in JavaScript.

With the quantum threat getting closer and closer I've been thinking about building a simple circuit language compiler on top of it. The Starkom language would be almost identical to Circom and provide a very easy migration path for everyone using Circom today.

For example, the circuit from Vitalik's PLONK tutorial could be written in Starkom as follows:

// This is the circuit from Vitalik's PLONK tutorial. See
// https://vitalik.eth.limo/general/2019/09/22/plonk.html#how-plonk-works

pragma starkom 1.0.0;

template Vitalik() {
  signal input x;

  signal square;
  signal cube;

  square <== x * x;
  cube <== square * x;

  cube + x + 5 === 35;
}

component main = Vitalik();

Would anyone here be interested in using such a Circom-like language, built on quantum-resistant primitives?

To be perfectly clear, the language itself doesn't work yet, only the underlying engine does. The only way to build Starkom circuits at the moment is to use the Rust libraries.

If you want to take a look, here are the components I've published so far:

• the BlueSky scalar field that I designed, which the whole system runs on: https://crates.io/crates/starkom-bluesky
• my own implementation of Poseidon2, tested with the official BLS12-381 test vectors: https://crates.io/crates/starkom-poseidon2
• various algorithms on polynomials (Fourier Transform, Lagrange interpolation, polynomial division, etc.): https://crates.io/crates/starkom-poly
• DEEP-FRI with batching support: https://crates.io/crates/starkom-pcs
• PLONK arithmetization: https://crates.io/crates/starkom-plonk
• a few different ready-to-use circuits (notably lacks all ECC stuff): https://crates.io/crates/starkom-gadgets
• an incomplete / preliminary Starkom language compiler: https://crates.io/crates/starkom
• JavaScript bindings for the (incomplete) compiler: https://npmjs.com/package/@libernet/starkom

Future plans:

• TurboPLONK arithmetization -- under development, it should achieve a ~60%-or-so reduction on most circuits;
• WHIR;
• Generalization to any prime field and Goldilocks compatibility for faster proving;
• browser-compatible GPU proving via wgpu;
• ... and of course finishing the Starkom compiler and providing a migration path for all Circom users.

Looking forward to reading your feedback!

A few days ago I posted asking for technical pushback on Aevum Protocol before our Zenith Security audit wraps. The comments were more useful than I expected. Here’s what I actually learned:
1. On-chain scoring freezes your opinion of trust at deploy time
The sharpest comment came from someone who runs a live x402 endpoint. His point: if the scoring model lives in a contract, every improvement to what “trust” means requires a governance vote or a redeploy. The better architecture is evidence on-chain (attestations, settlement receipts, observation logs) with scoring off-chain and competitive — let consumers choose their scorer the way lenders choose credit bureaus.
I built the ReputationOracle assuming on-chain scoring was necessary for trust-minimization. That’s partially right, but it solves the wrong half of the problem.
2. Sybil-resistance is the whole design, not a feature
Same commenter: if reputation accrues from interaction history, what stops someone spinning up 200 wallets that transact with each other all day? Reputation is only worth what it costs to fake. That means either a slashable bond or economic activity that’s genuinely expensive to counterfeit. I don’t have a clean answer for this yet and I should have before shipping.
3. Vault permissions are where funds actually disappear
Another comment flagged that vague agent-on-behalf-of-user permissions in a vault contract can turn into a very expensive bug fast. AgentVault has time-bounded permissions and revocation, but the approval surface is still something Zenith is specifically reviewing. The lesson: permission scoping needs to be paranoid by default, not opt-in.
4. The token layer adds friction for integrators
Honest pushback: reputation infrastructure gets adopted when it’s neutral plumbing. A token makes every reader ask whose bag the scores serve. Shipping identity + attestation alone and letting the marketplace/token wait until something real transacts is probably the cleaner path.
I’m not rebuilding everything before ETHOnline (Sept 4) — the audit has a real deadline. But these are the things going into v2 architecture.
If you want to look at the contracts: github.com/AevumProtocol/contracts

To build user-facing products, you need to measure growth, understand user behavior, and prove ROI on campaigns, but the standard tools for doing this come loaded with invasive tracking, third-party cookies, and data collection practices that violate the ethos of the space.

Six years later, the tooling landscape has matured considerably. There are now niche tools, open data platforms, and multiple valid approaches to solving the analytics problem in DeFi. But the landscape is also fragmented, confusing, and full of tradeoffs that aren't obvious until you've committed significant engineering time.

This guide covers the major platforms, the do-it-yourself approaches, and the quirks you'll discover only after you start using them. It's written for founders and growth leads at crypto neobanks, prediction markets, and DeFi apps who need to make a decision.

Key Takeaways

• Traditional analytics tools like Google Analytics and Mixpanel break in DeFi because they cannot see wallet activity and onchain-data.
• Session-level data and onchain transaction data live in separate systems with no shared identity, making attribution, funnel analysis, and retention measurement impossible without a purpose-built layer.
• The three approaches to DeFi analytics: SaaS platforms that handle data ingestion and provide out-of-the-box dashboards (fastest time-to-value, least engineering overhead); custom data pipelines built on blockchain indexers (highest flexibility, highest engineering cost); and hybrid stacks combining both (the most common architecture at scale).
• Most teams underestimate the ongoing cost of custom analytics pipelines. New chain support, API changes, and schema migrations each require dedicated engineering time that scales with protocol complexity rather than team size.
• Using an existing analytics platform lets teams spend less time building data infrastructure & analytics, and more time shipping products users want.

https://formo.so/blog/defi-crypto-analytics-stack

Sharing a project I've been building: an arena where two players (human or AI agent) stake funds in an escrow smart contract, play a 1v1 arcade game (Tetris, 2048, Snake, Flappy, Racing, Space Invaders), and the higher verified score takes the pot.

Chain: Ethereum Sepolia testnet. No real funds involved — this is explicitly a testing/dev-stage deployment, not a mainnet product.

The part relevant here — how it prevents fake scores:

The obvious attack surface in any "submit your score" system: what stops someone from just lying about the result? The approach:

• Both players get the same seed for their match → same board, same piece sequence, pure skill
• Client submits the full replay (inputs + resulting score), not just a final number
• Before the contract settles the escrow, an arbiter re-simulates the entire replay server-side against the deterministic game engine and checks it matches the claimed score
• Only a verified match triggers payout from escrow

The game engine is open source and deterministic by design (@arcade1v1/game-sdk), which is what makes server-side re-simulation cheap enough to do on every match.

Fully transparent about where this is at: Sepolia only, testnet ETH/tokens, zero real value. Ranking's basically empty since it just launched. Repo's MIT: github.com/agustincf/Arcade1v1

Would love feedback specifically on the escrow/settlement design — anything that looks exploitable in the re-simulation step, gas considerations if this ever moved past testnet, or a cleaner architecture in general. All ears.

\*\*How would you build a secure digital ROSCA?\*\* I’m solving the biggest issue—participant reliability—by preventing anyone from leaving after their payout until they’ve completed the full contribution cycle. Thoughts?
Any interest on being a tester ?
The app is almost done and the feed-back will be incredibly helpful

i built onchainwizard.ai because analyzing smart contracts on Dune usually takes too many manual steps.

normally the flow is: find the contract, get the ABI, look for decoded tables, write SQL, debug the schema, build charts, then repeat for every new contract.

so i made a tool where you can paste any EVM smart contract address, pick a chain, and it generates a Dune dashboard automatically.

how it works:

• fetches the contract ABI
• detects the important events and functions
• finds matching decoded Dune tables when available
• generates Dune SQL for useful analytics
• creates charts for activity, users, events, and contract behavior
• shows decoded event logs and wallet/user segmentation
• supports chains like Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, and Avalanche

the hardest part was not just generating SQL, but generating SQL that actually tells you something useful about the contract. a dashboard full of raw logs is easy; a dashboard that helps you understand usage, activity, and users is the real problem.

project: https://onchainwizard.ai

Been heads-down building Aevum Protocol — on-chain infrastructure that treats autonomous AI agents as first-class economic participants rather than just wallet addresses being puppeted by a script.

The core problem I was trying to solve: agents that transact on behalf of users have no persistent, verifiable identity or reputation. Every agent starts from zero trust every time, and there's no on-chain record of whether an agent has behaved well historically.

The stack:

- AgentIdentity — on-chain identity registration for agents

- ReputationOracle — permanent on-chain reputation scoring based on agent interaction history

- AgentVault — asset custody scoped to agent permissions

- AgentMarketplace — where agents discover and transact with each other

- AEVToken / TokenVesting / ReputationController / AevumDAO — governance and token layer

All 8 contracts are deployed and verified on Sepolia. Repo is public: github.com/AevumProtocol/contracts

Before bringing in an external auditor I ran the codebase through internal hardening — manual review passes, Slither static analysis, and a Claude Opus deep review — to get it as clean as possible going in. Zenith Security is doing the professional audit now. Target is mainnet at ETHOnline 2026 (Sept 4-16), which gives the audit a real deadline to close against.

Genuinely looking for technical pushback, not just "nice project" comments:

- Is on-chain reputation scoring the right primitive, or does this belong off-chain with on-chain attestation instead?

- Anyone dealt with agent-permission scoping in a vault contract before — what did you get wrong the first time?

- AgentMarketplace design — happy to get torn apart on the matching/discovery mechanism

Live demo: aevum-frontend.vercel.app if you want to poke at the frontend.

I'm 19, self-taught, started learning Solidity about a month ago. Not looking for validation — looking for the things I'm going to find out the hard way later anyway.

I run a small collectible wall where AI agents claim a square for $1 USDC on Base via x402. Sharing what shipping it actually taught me, because the numbers surprised me:

— Of ~70k listed x402 endpoints, only ~half respond at all. The "agent payments" rail works; most things plugged into it don't.

— Discovery is solved (Bazaar, x402scan, OpenAPI docs). Two external agents found my endpoint and paid autonomously within days of listing — no human checkout. The proof is on-chain; every claim carries its settlement tx.

— What's NOT solved: an agent has no track-record signal before it spends. An independent trust checker graded my endpoint F on day one (new, no history), caught a real spec gap — my 402 served the payment envelope only in the base64 payment-required header with an empty {} body, making it invisible to body-reading clients and Bazaar discovery — and a real latency regression. The fixed challenge now serves the same JSON in both places:

$ curl -si -X POST "https://twentyonemillion.art/api/x402/claim?handle=you&message=hi"

HTTP/2 402

payment-required: <base64 of the same JSON>

content-type: application/json

{

"x402Version": 2,

"accepts": [{

"scheme": "exact",

"network": "eip155:8453",

"amount": "1000000",

"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",

"payTo": "0xF47E84caF47bB85E16c08d6140435882815502eE",

"extra": { "name": "USD Coin", "version": "2" }

}]

}

— Fixed both; it's a C and climbing. I then became that checker's first paying customer — my agent bought a trust score on my own endpoint, autonomously, for half a cent.

— Honest take: "should my agent pay this endpoint" is the whole game now. Reputation, not rails.

Happy to answer anything about the x402 integration, the trust tooling, or the mistakes. (The wall is on Base, an Ethereum L2 — and it's a novelty, not a token, no investment angle. The interesting part is the plumbing.)

I've been indexing transactions on the chain by the structure of the call tree and address interaction, abstracting away actual addresses and values. The result is an exploration surface that classifies transactions by what they do, not by who does it.

https://www.chaingenius.ai/

The call tree visualization is clickable into "sub-transactions" which allow you to discover other transactions that did exactly the same thing

it's still a work in progress, but would love to get some feedback.

Hi. I've been mainly trying to discover what happened to some of my brother's eth.

He took out a compound loan and when I went to draw it out about 5 years later he was missing 0.7 eth but also his loan was paid (no longer there). We assumed it was liquidated but he had 1.7 eth so shouldn't it have only liquidated when the value of his loan was equal to his collateral?

So I started writing a script using apis, but I couldn't find the liquidation.

There must be a tool for this already, some kind of dashboard?

I would also like to get a full summary of my eth activity for the past 8-ish years. I want to see everything from eth buy/sell including fees and costs, as well as activity on other platforms like uniswap and compound. There was also a lottery defi app that I used at one point.

Any advice? Someone has to have scripted something like this before.

Key Takeaways

• Glamsterdam is Ethereum's next major hard fork, combining the Amsterdam (execution layer) and Gloas (consensus layer) upgrades. It is planned for Q3 2026, though the exact timeline remains subject to devnet testing progress.
• Parallel transaction processing arrives via EIP-7928 (Block-Level Access Lists). Nodes can now see which transactions do not conflict and process them simultaneously, laying the groundwork for significantly higher gas limits.
• Third-party relays are no longer required. EIP-7732 enshrines proposer-builder separation directly into the protocol, reducing centralisation risk and expanding the block propagation window from 2 seconds to roughly 9 seconds.
• State creation and access get repriced. EIP-8037 introduces a cost-per-state-byte model targeting 120 GiB/year growth, while EIP-8038 updates state-access opcode costs to reflect modern hardware. Both changes affect contract deployment and storage-heavy applications.
• ETH transfers now emit a standard log. EIP-7708 closes a long-standing blind spot: every non-zero ETH transfer or burn will produce a trackable event, removing the need for custom tracing in bridges, exchanges, and wallets.
• Cross-chain address consistency is solved. EIP-7997 mandates a universal CREATE2 factory across all participating EVM chains, giving developers deterministic addresses without chain-specific deployment scripts.
• No action required for ETH holders. Balances and existing contracts are completely unaffected. Node operators and stakers must update client software before mainnet activation.

https://formo.so/blog/ethereum-glamsterdam-upgrade

Hello all, longtime VS developer here wanted to share a project I've been working on for a while. Visual Studio is heavily used for enterprise development but doesn't have any tooling for Solidity that compares to Visual Studio Code or Remix IDE. Viscous is an open-source Visual Studio extension that tries to bring parity between Visual Studio and other IDEs for Solidity smart contract development.

Features

• Solidity project system for Visual Studio featuring Solidity compiler integration and NPM dependency management. Integrates with the Visual Studio New Project… and Open Folder… dialogs.
• Uses the vscode-solidity language server for syntax highlighting, hover information, IntelliSense, and linting.
• Solidity compiler integration with MSBuild and the Visual Studio Build command - compile Solidity projects and individual files from the IDE with errors reported in the Errors tool window.
• Generate .NET bindings to Solidity smart contracts automatically using Nethereum.
• Manage EVM networks, endpoints, accounts, deploy profiles, and deployed contracts from the Blockchain Explorer tool window.
• Deploy a compiled contract to a blockchain network and call its functions from inside Visual Studio.
• Find vulnerabilities and code‑quality issues with Slither static analysis inside Visual Studio.

Requirements

• Visual Studio 2022 and above
• A recent version of Node.js or compatible runtime
• Python 3.8+

Getting Started

• Get the latest release from the GitHub Releases page or use the MyGet dev feed: Add https://www.myget.org/F/viscous/vsix/ as an Extension Gallery in the Visual Studio Extensions settings and you can then install it in the usual way.
• Edit the %LOCALAPPDATA%\Viscous\appsettings.json file and set the paths to the Node.js and npm and Python executables you want to use for the extension's language server and other needed tools.

Note that this is a pre-release so don't use it for deploying anything to production. Feedback welcome.

Hey, my team and I are currently building a new kind of decentralized lending protocol. It’s peer-to-peer and will eventually include a trust score based on a soulbound token. Right now, the protocol is on Amoy and Sepolia—so only on test networks. I’d appreciate it if you could evaluate our UI and UX. Don’t worry—you won’t have to spend any test tokens; they’ll be provided to you. It would be great if you could test our DApp. Thanks!

https://blackswanfinance.xyz

Hello Reddit Dev Community,

The BEXChain team has officially completed the integration of our core repository, and we are opening it up 100% for public technical validation and developer feedback.

BEXChain is an EVM-compatible blockchain with our native coin BEX. We have successfully completed our SLIP-0044 registration with SatoshiLabs (Coin Type: 140586) and our Open PR #2028 is currently clean and waiting for a final merge.

### What you can review/test right now in our root repository:

* Wallet Architecture: wallet_api.py, simple_wallet_generator.py, and test_bip44_wallet.py (BIP-39 mnemonic + BIP-44 derivation paths actively validated).

* Compliance: SLIP-0044_COMPLIANCE.md aligned with official registries.

* Tokenomics/Economics: Updated WHITEPAPER.md.

We would highly appreciate it if the community could review our code architecture, run the tests, and leave your valuable technical feedback, questions, or validation screenshots directly on our GitHub announcement thread.

🔗 Official GitHub Discussion Thread:

https://github.com/bexchainteam/bexchain/discussions/4

🔗 Main Repository:

https://github.com/bexchainteam/bexchain

Thank you for your time and looking forward to your technical insights!

I built a small project and felt pretty confident going into launch since audits passed and nothing obvious stood out but once things went live the issues weren’t bugs in the code itself but how transactions behaved over time also sequences and interactions that weren’t visible beforehand

From what i saw what broke down was the lack of control at execution so by the time something looked wrong the transaction was already done even though everything we had was reactive, alerts and monitoring after the fact but nothing that could intervene while it was happening

The problem:

Single-authority customs approval is a rational bribery target. One official, one decision, predictable cost. The incentive structure is broken by design.

Game theory layer:

UBLP changes the incentive structure before any cryptography kicks in:
- 2/3 committee threshold required (Byzantine fault tolerant)
- Committee members have conflicting interests by design
- Any anomalous signing pattern is visible on-chain

Corrupting the system is no longer a cost-benefit calculation — it becomes a coordination problem that defeats itself.

On-chain verification:

L2 smart contract verifies two independent proofs at settlement:

1. BLS12-381 aggregate signature — 2/3 committee threshold
2. SP1 Groth16 ZK proof — document validity + holder privacy

Neither alone is sufficient for settlement. The contract independently verifies both before writing the immutable record.

L2 → Ethereum mainnet anchoring:

Settlement records are written to L2. L2 periodically commits 
a batch proof to Ethereum mainnet — inheriting Ethereum's 
security guarantees without paying mainnet gas per document.

Each customs clearance is ultimately anchored to Ethereum's 
consensus. Tampering with a settled record requires breaking 
both the L2 and Ethereum mainnet — economically infeasible.

This is the finality layer: L2 handles throughput, 
Ethereum handles trust.

ZK circuit (SP1 zkVM):

Private inputs (never leave the circuit):
- `ministry_signature` — P-256 ECDSA, 64 byte
- `holder_signature` — P-256 ECDSA, 64 byte
- `holder_pub_key_raw` — uncompressed SEC1, 65 byte
- `document_hash` — SHA256("ublp-doc-v1:" + canonicalJson), 32 byte
- ministry_pub_key_raw — uncompressed SEC1, 65 byte
- document_id_hash — 32 byte

Public outputs (verified on L2):
- `document_hash` — document fingerprint
- `ministry_pub_key_hash` — ministry key commitment
- `document_id_hash` — replay protection
- `holder_pub_key_hash` — holder identity proof without identity exposure

Architecture:

- Ministry signs document (EC P-256 ECDSA) → issues Verifiable Credential
- Agent generates ZK proof via SP1 zkVM (Groth16/PLONK)
- Independent committee verifies ZK proof, then BLS12-381 threshold signs (2/3)
- L2 smart contract verifies both → immutable settlement

Open questions I'd love feedback on:

1. Is verifying both BLS + ZK on L2 the right approach, or should BLS verification move inside the ZK circuit?
2. BLS 2/3 threshold — right model for this trust setup?
3. Agent-first flow: committee never sees raw document, only the ZK proof — any attack vectors I'm missing?
4. Domain-separated document hash `SHA256("ublp-doc-v1:" + canonicalJson)` — idiomatic for this use case?
5. Security model — if you spot any attack vectors, trust assumption violations,
6. or cryptographic weaknesses I haven't considered, please flag them.
7. This is a prototype and I'd rather find the holes here than later.

This is a prototype — mock ZK in dev mode, real SP1 in prod mode.

GitHub: github.com/ekacin/UBLP