https://aleoforagents.com/blog Weekly ecosystem digests, project tutorials, and deep dives into Aleo en-us Wed, 08 Apr 2026 18:21:01 GMT https://aleoforagents.com/blog/2026-04-08-aleo-this-week-dynamic-dispatch-lands-on-mainnet-leo-4-0-stabilizes SDK v0.10.1 brings dynamic dispatch to mainnet, while Leo 4.0 spends a week fixing the bugs that usually surface after a big language jump. snarkOS also drops i Wed, 08 Apr 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-04-08-aleo-this-week-dynamic-dispatch-lands-on-mainnet-leo-4-0-stabilizes lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-04-08-deep-dive-why-leo-s-stub-ordering-bug-exposes-aleo-s-real-composability-boundary Dynamic dispatch did not move Aleo's composability boundary all the way to runtime. Once imported CPIs started carrying `Final`, real interoperability began dep Wed, 08 Apr 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-04-08-deep-dive-why-leo-s-stub-ordering-bug-exposes-aleo-s-real-composability-boundary lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-26-aleo-this-week-leo-4-0-gets-real Leo 4.0 stopped sounding like a roadmap bullet this week. Dynamic calls, `dyn record`, library functions, ABI renames, and SDK signing changes all landed togeth Thu, 26 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-26-aleo-this-week-leo-4-0-gets-real lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-26-deep-dive-why-snarkvm-s-record-existence-guarantee-matters-more-than-leo-4-0-s-d Leo 4.0's `dyn record` syntax is only safe because snarkVM now checks that every dynamic or external record seen during an execution resolves to a real ledger r Thu, 26 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-26-deep-dive-why-snarkvm-s-record-existence-guarantee-matters-more-than-leo-4-0-s-d lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-26-off-chain-proof-gateways-with-leo-and-the-provable-sdk A step-by-step tutorial for building a bounded-amount claim circuit in Leo 4.0 with fn-style entry points and verifying proofs off-chain in TypeScript using the Provable SDK. field { let claim: PurchaseClaim = PurchaseClaim { amount: amount, nonce: nonce, }; return BHP256::hash_to_field(claim); } transition quote_claim_hash(amount: u64, nonce: field) -> field { assert(amount > 0u64); return claim_hash(amount, nonce); } transition prove_under_limit( public claim_hash: field, amount: u64, nonce: field, ) -> field { assert(amount > 0u64); assert(amount <= 1000u64); let expected_hash: field = claim_hash(amount, nonce); assert_eq(expected_hash, claim_hash); return claim_hash; } } ``` Current Leo syntax wants the program body wrapped in braces, the constructor policy written as `@noupgrade`, and CLI-callable entry points exposed as `transition`s. I kept the shared hash logic in an `inline` helper so the quote path and the proof path still use the same construction. I dropped the record output from the earlier draft. For this pattern the proof is the product, so returning the public hash keeps the circuit small and avoids extra moving parts that do not help the verifier. Now build, dry-run the helper, and generate an execution artifact: ```bash leo build leo run quote_claim_hash 42u64 7field ``` If you want the hash in a shell variable: ```bash CLAIM_HASH=$(leo run quote_claim_hash 42u64 7field --json-output | jq -r 'if .output then .output elif .outputs then (if (.outputs | type) == "array" then .outputs else .outputs end) else empty end') echo "$CLAIM_HASH" ``` Then execute the proof path: ```bash leo execute prove_under_limit $CLAIM_HASH 42u64 7field --json-output > execution.json ``` That `execution.json` file is the hand-off point. Depending on the exact CLI build you are on, the proof, verifying key, and public inputs may sit under slightly different keys, so the verifier should handle small shape changes instead of assuming one exact layout forever. ## Verifier Create `verify.ts` in the project root: ```typescript import { snarkVerify } from '@provablehq/sdk/mainnet.js'; import { createHash } from 'node:crypto'; import { readFile, writeFile } from 'node:fs/promises'; type JsonRecord = Record; function pick(obj: JsonRecord, paths: string[][]): unknown { for (const path of paths) { let current: unknown = obj; let ok = true; for (const key of path) { if (typeof current !== 'object' || current === null || !(key in current)) { ok = false; break; } current = (current as Record)[key]; } if (ok && current !== undefined && current !== null) { return current; } } throw new Error(`Missing expected field: ${paths.map((p) => p.join('.')).join(', ')}`); } function asArray(value: unknown): unknown[] { return Array.isArray(value) ? value : [value]; } const raw = await readFile('./execution.json', 'utf8'); const execution = JSON.parse(raw) as JsonRecord; const proof = pick(execution, [ ['proof'], ['execution', 'proof'], ['response', 'proof'], ]); const verifyingKey = pick(execution, [ ['verifying_key'], ['verifyingKey'], ['execution', 'verifying_key'], ['execution', 'verifyingKey'], ]); const publicInputs = pick(execution, [ ['public_inputs'], ['publicInputs'], ['execution', 'public_inputs'], ['execution', 'publicInputs'], ]); const verified = await snarkVerify(verifyingKey, publicInputs, proof); if (!verified) { throw new Error('Proof verification failed'); } const claimHash = String(asArray(publicInputs)); const receiptPayload = { claimHash, programId: 'offchain_gateway.aleo', functionName: 'prove_under_limit', verifiedAt: new Date().toISOString(), verifier: 'provable-sdk-snarkVerify', status: 'accepted', }; const receiptId = createHash('sha256') .update(JSON.stringify(receiptPayload)) .digest('hex'); await writeFile( './receipt.json', JSON.stringify({ receiptId, ...receiptPayload }, null, 2), ); console.log(`Verified proof for ${claimHash}`); console.log(`Wrote receipt.json with id ${receiptId}`); ``` Run it with: ```bash npx tsx verify.ts ``` If the proof checks out, you will get `receipt.json`. The verifier should be strict and the receipt should be boring. If verification fails, stop there. A maybe-receipt is useless. ## Testing and fit Test the path that should pass: ```bash CLAIM_HASH=$(leo run quote_claim_hash 42u64 7field --json-output | jq -r 'if .output then .output elif .outputs then (if (.outputs | type) == "array" then .outputs else .outputs end) else empty end') leo execute prove_under_limit $CLAIM_HASH 42u64 7field --json-output > execution.json npx tsx verify.ts cat receipt.json ``` Test the path that should fail in the circuit: ```bash CLAIM_HASH=$(leo run quote_claim_hash 1001u64 7field --json-output | jq -r 'if .output then .output elif .outputs then (if (.outputs | type) == "array" then .outputs else .outputs end) else empty end') leo execute prove_under_limit $CLAIM_HASH 1001u64 7field --json-output > execution.json ``` And test a tampered public statement by generating a valid proof, editing `execution.json`, changing the first public input, and running the verifier again: ```bash npx tsx verify.ts ``` Those three checks cover the cases that matter. One proves the normal path works, one proves the circuit rejects bad witnesses, and one proves the receipt is tied to the same public statement the prover committed to. This pattern is a good fit for gated downloads, checkout approvals, eligibility checks, or proof-backed access passes. If you later need shared settlement or public composability, move verification on-chain for that flow and pay consensus only where it buys you something real.]]> Thu, 26 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-26-off-chain-proof-gateways-with-leo-and-the-provable-sdk lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-22-build-a-signature-permit-gate-for-aleo-token-registry-flows This rewrite pares the controller down to one compile-safe Leo 3.5 pattern: a typed `Permit` message hashed with `BHP256::hash_to_field`, a `used_nonces` mappin address; mapping used_nonces: field => bool; mapping allowances: field => u64; inline hash_permit( owner: address, spender: address, token_id: field, amount: u64, nonce: u64, expires_at: u32, ) -> field { let permit: Permit = Permit { grantor: owner, spender: spender, token_id: token_id, amount: amount, nonce: nonce, expires_at: expires_at, }; return BHP256::hash_to_field(permit); } inline hash_nonce(owner: address, nonce: u64) -> field { let key: NonceKey = NonceKey { grantor: owner, nonce: nonce, }; return BHP256::hash_to_field(key); } inline hash_allowance(owner: address, spender: address, token_id: field) -> field { let key: AllowanceKey = AllowanceKey { grantor: owner, spender: spender, token_id: token_id, }; return BHP256::hash_to_field(key); } async transition initialize(public admin_addr: address) -> Future { return finalize_initialize(admin_addr); } async function finalize_initialize(admin_addr: address) { let exists: bool = Mapping::contains(admins, true); assert(!exists); Mapping::set(admins, true, admin_addr); } transition permit_hash( public owner: address, public spender: address, public token_id: field, public amount: u64, public nonce: u64, public expires_at: u32, ) -> field { return hash_permit(owner, spender, token_id, amount, nonce, expires_at); } transition allowance_key( public owner: address, public spender: address, public token_id: field, ) -> field { return hash_allowance(owner, spender, token_id); } async transition submit_permit( public owner: address, public spender: address, public token_id: field, public amount: u64, public nonce: u64, public expires_at: u32, sig: signature, ) -> (PermitReceipt, Future) { assert(amount > 0u64); let message_hash: field = hash_permit(owner, spender, token_id, amount, nonce, expires_at); let valid: bool = signature::verify(sig, owner, message_hash); assert(valid); let nonce_key: field = hash_nonce(owner, nonce); let allow_key: field = hash_allowance(owner, spender, token_id); let receipt: PermitReceipt = PermitReceipt { owner: spender, grantor: owner, spender: spender, token_id: token_id, amount: amount, nonce: nonce, expires_at: expires_at, }; return (receipt, finalize_submit_permit(nonce_key, allow_key, amount)); } async function finalize_submit_permit(nonce_key: field, allow_key: field, amount: u64) { let seen: bool = Mapping::get_or_use(used_nonces, nonce_key, false); assert(!seen); let current: u64 = Mapping::get_or_use(allowances, allow_key, 0u64); Mapping::set(used_nonces, nonce_key, true); Mapping::set(allowances, allow_key, current + amount); } async transition bootstrap_allowance( public owner: address, public spender: address, public token_id: field, public amount: u64, ) -> (PermitReceipt, Future) { assert(amount > 0u64); let signer: address = self.signer; let allow_key: field = hash_allowance(owner, spender, token_id); let receipt: PermitReceipt = PermitReceipt { owner: spender, grantor: owner, spender: spender, token_id: token_id, amount: amount, nonce: 0u64, expires_at: 0u32, }; return (receipt, finalize_bootstrap_allowance(signer, allow_key, amount)); } async function finalize_bootstrap_allowance(signer: address, allow_key: field, amount: u64) { let admin_addr: address = Mapping::get(admins, true); assert_eq(signer, admin_addr); let current: u64 = Mapping::get_or_use(allowances, allow_key, 0u64); Mapping::set(allowances, allow_key, current + amount); } async transition consume_allowance( public owner: address, public spender: address, public token_id: field, public amount: u64, ) -> Future { assert(amount > 0u64); assert_eq(self.signer, spender); let allow_key: field = hash_allowance(owner, spender, token_id); return finalize_consume_allowance(allow_key, amount); } async function finalize_consume_allowance(allow_key: field, amount: u64) { let current: u64 = Mapping::get_or_use(allowances, allow_key, 0u64); assert(current >= amount); Mapping::set(allowances, allow_key, current - amount); } async transition set_admin(public next_admin: address) -> Future { let signer: address = self.signer; return finalize_set_admin(signer, next_admin); } async function finalize_set_admin(signer: address, next_admin: address) { let current_admin: address = Mapping::get(admins, true); assert_eq(signer, current_admin); Mapping::set(admins, true, next_admin); } } ``` ## How the gate works `Permit` is the signed payload. In the public API the signer is still called `owner`, but inside the helper structs I renamed that field to `grantor` because Leo reserves `owner` for records. - `owner`: the account granting permission. - `spender`: the account allowed to use it. - `token_id`: the registry asset this applies to. - `amount`: the approved spend. - `nonce`: replay protection. - `expires_at`: an expiry value you can pass downstream. `submit_permit` hashes that struct, verifies the signature, derives a nonce key, derives an allowance key, and then hands state changes to `finalize_submit_permit`. That split matters. The proof-side work stays in the transition body, while public state updates stay in the finalize block where Leo expects them. The gate keeps two public mappings: - `used_nonces` marks a permit as spent the first time it lands. - `allowances` tracks how much room is left for a specific owner, spender, and token. `consume_allowance` is the piece you actually care about in production. The spender has to be the signer, the amount has to be positive, and the remaining allowance has to cover the request. One design choice is deliberate: this example carries `expires_at` through the signed payload and the receipt, but it does not pretend to enforce wall-clock time by itself. The clean place to enforce expiry is the registry-side authorization path that already deals with live chain context. ## Local checks Build first. ```bash leo build ``` Then run the two pure helpers. They are boring on purpose. If your wallet, backend, and Leo code do not agree on these hashes, stop there and fix that before you wire anything into a registry path. ```bash leo run permit_hash aleo1qnr4dkkvkgfqph0vzc3y6z2eu975wnpz2925ntjccd5cfqxtyu8s7pyjh9 aleo19y2eyc2cycvdqmycqam60l6uexvfj468xcet65jnnzc5pn8g9ufqg2clp2 999field 25u64 1u64 5000u32 leo run allowance_key aleo1qnr4dkkvkgfqph0vzc3y6z2eu975wnpz2925ntjccd5cfqxtyu8s7pyjh9 aleo19y2eyc2cycvdqmycqam60l6uexvfj468xcet65jnnzc5pn8g9ufqg2clp2 999field ``` For a quick state-path check, initialize the admin slot, seed a test allowance, and consume part of it. ```bash leo execute initialize aleo1qnr4dkkvkgfqph0vzc3y6z2eu975wnpz2925ntjccd5cfqxtyu8s7pyjh9 leo execute bootstrap_allowance aleo1qnr4dkkvkgfqph0vzc3y6z2eu975wnpz2925ntjccd5cfqxtyu8s7pyjh9 aleo19y2eyc2cycvdqmycqam60l6uexvfj468xcet65jnnzc5pn8g9ufqg2clp2 999field 25u64 leo execute consume_allowance aleo1qnr4dkkvkgfqph0vzc3y6z2eu975wnpz2925ntjccd5cfqxtyu8s7pyjh9 aleo19y2eyc2cycvdqmycqam60l6uexvfj468xcet65jnnzc5pn8g9ufqg2clp2 999field 10u64 ``` After that, switch to the real path: 1. Have the owner sign the field returned by `permit_hash`. 2. Submit that signature to `submit_permit`. 3. Call `consume_allowance` from the permitted spender account. 4. Fail hard on any mismatch in owner, spender, token, amount, or nonce. The negative tests matter more than the happy path: - Reuse the same nonce. It must fail. - Try to spend more than the stored allowance. It must fail. - Call `consume_allowance` from an address that is not the permitted spender. It must fail. - Keep owner and spender the same but swap `token_id`. It must fail. Permit code is security code wearing application clothes. Treat it that way. ## Wiring it into a registry flow A production flow usually looks like this: 1. Register the asset with external authorization turned on. 2. Point that authorization path at your permit controller. 3. Have the owner sign a permit off-chain. 4. Submit the permit once so the controller records allowance and burns the nonce. 5. When the spend request arrives, call `consume_allowance` before letting the asset move. That gives you a neat split of duties. The registry keeps custody and token rules. The permit gate handles delegated spend policy. ## Next changes I would make First, move real expiry enforcement into the registry-facing authorization call where chain time is available. Carrying `expires_at` without a time check is fine for a local demo, but not enough for production. Second, replace `bootstrap_allowance` with a wallet or SDK signing path as soon as you have one. The helper is useful for smoke tests, then it should disappear. Third, decide whether you even want the `PermitReceipt` record. I like it because it gives private flows a concrete artifact to pass around, but some apps will prefer a slimmer interface with no receipt at all. That is the whole pattern in a compact form: one signed message, one nonce burn, one allowance bucket, and one spend check before anything valuable moves.]]> Sun, 22 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-22-build-a-signature-permit-gate-for-aleo-token-registry-flows lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-22-deep-dive-what-v4-6-0-canary-really-signals-and-why-arc-0043-s-zk-snark-puzzle-m Aleo's coinbase puzzle already rewards useful proving work, but it still sits outside the chain's main zk proof model as a proof-of-work style threshold game. A Sun, 22 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-22-deep-dive-what-v4-6-0-canary-really-signals-and-why-arc-0043-s-zk-snark-puzzle-m lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-18-aleo-this-week-faster-test-loops-merkle-optimizations-and-amendment-plumbing Leo now skips proof generation in `leo test` unless you ask for it, which cuts local feedback time and makes failing tests fail properly at the CLI level. Meanw Wed, 18 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-18-aleo-this-week-faster-test-loops-merkle-optimizations-and-amendment-plumbing lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-18-deep-dive-why-leo-interface-constrained-records-could-become-aleo-s-real-app-sta Leo's new interface record coercion could make record shape, not just function names, the real app standard on Aleo. That matters because Aleo still depends on Wed, 18 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-18-deep-dive-why-leo-interface-constrained-records-could-become-aleo-s-real-app-sta lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-18-proof-gated-attestation-in-leo-a-minimal-snark-verify-verifier This post builds `proof_gated_attestation.aleo`, a Leo program that gates on-chain attestation records behind an external zero-knowledge proof checked with `sna field; mapping config_ready: u8 => bool; mapping total_claims: u8 => u64; mapping claimed: field => bool; record ClaimReceipt { owner: address, claim_id: field, subject: field, schema: field, issuer_id: field, } struct ClaimIdInput { subject: field, schema: field, salt: field, } struct ClaimData { claim_id: field, subject: field, schema: field, issuer_id: field, } transition derive_claim_id( public subject: field, public schema: field, public salt: field ) -> field { let input: ClaimIdInput = ClaimIdInput { subject: subject, schema: schema, salt: salt, }; return BHP256::hash_to_field(input); } transition derive_public_inputs_hash( public claim_id: field, public subject: field, public schema: field, public issuer_id: field ) -> field { let data: ClaimData = ClaimData { claim_id: claim_id, subject: subject, schema: schema, issuer_id: issuer_id, }; return BHP256::hash_to_field(data); } async transition initialize( public issuer_id: field, public verifier_key_hash: field ) -> Future { return finalize_initialize(issuer_id, verifier_key_hash); } async function finalize_initialize( issuer_id: field, verifier_key_hash: field ) { let ready: bool = config_ready.get_or_use(0u8, false); assert_eq(ready, false); config_fields.set(0u8, issuer_id); config_fields.set(1u8, verifier_key_hash); total_claims.set(0u8, 0u64); config_ready.set(0u8, true); } async transition claim( public claim_id: field, public subject: field, public schema: field, public issuer_id: field, public public_inputs_hash: field, public verifier_key_hash: field ) -> (ClaimReceipt, Future) { let receipt: ClaimReceipt = ClaimReceipt { owner: self.signer, claim_id: claim_id, subject: subject, schema: schema, issuer_id: issuer_id, }; return ( receipt, finalize_claim( claim_id, subject, schema, issuer_id, public_inputs_hash, verifier_key_hash ) ); } async function finalize_claim( claim_id: field, subject: field, schema: field, issuer_id: field, public_inputs_hash: field, verifier_key_hash: field ) { let ready: bool = config_ready.get_or_use(0u8, false); assert_eq(ready, true); let stored_issuer_id: field = config_fields.get_or_use(0u8, 0field); let stored_vk_hash: field = config_fields.get_or_use(1u8, 0field); assert_eq(issuer_id, stored_issuer_id); assert_eq(verifier_key_hash, stored_vk_hash); let data: ClaimData = ClaimData { claim_id: claim_id, subject: subject, schema: schema, issuer_id: issuer_id, }; let expected_hash: field = BHP256::hash_to_field(data); assert_eq(public_inputs_hash, expected_hash); let already_claimed: bool = claimed.get_or_use(claim_id, false); assert_eq(already_claimed, false); claimed.set(claim_id, true); let current_total: u64 = total_claims.get_or_use(0u8, 0u64); total_claims.set(0u8, current_total + 1u64); } } ``` A few things are doing real work here. `initialize` replaces the old constructor idea. It writes config once, and `config_ready` makes sure nobody can quietly reconfigure the program later. `claimed` is the replay guard. Once a `claim_id` lands, the same claim cannot be recorded again. Public state is the right place for that check because duplicate prevention has to be globally visible. `ClaimReceipt` is private because it is a record. The chain keeps the minimal public fact, that a claim ID was accepted. The user keeps a receipt they can carry into another Leo flow later. `ClaimIdInput` and `ClaimData` are the two hashing structs. The previous version used `inline` helper functions with array-literal hashing, and that is where the compiler gave up. `BHP256::hash_to_field` with a struct keeps the field order explicit and works in both transitions and finalize blocks. `derive_public_inputs_hash` and the matching computation inside `finalize_claim` both construct a `ClaimData` struct and call `BHP256::hash_to_field` on it. Same struct, same field order, same hash. If your outside verifier is hashing something else, the mismatch will show up as a failed `assert_eq` in finalize rather than a silent wrong answer. `claim` has two jobs. Off-chain, it builds the receipt record. On-chain, inside `finalize_claim`, it checks that config exists, compares the configured values, recomputes the public-input hash, rejects duplicates, then increments a counter. The actual outside proof check has to happen before this Leo call. ### 3. Understand the trust model Here is the mental model I want you to keep. The prover is allowed to do expensive work. The prover is not allowed to decide truth by itself. In this corrected version, your verifier service decides whether the proof is valid, and the Leo program decides whether the public claim data matches the pinned config and has not been used before. That is a weaker trust boundary than true on-chain proof verification. I do not love that, but pretending the compiler supports symbols it does not support would be worse. If you build this today, keep the verifier in code you control, audit the path that turns a passed proof into a `claim` call, and keep the on-chain side narrow. Because Leo 3.5 does not give us constructors, config becomes an explicit first step. That is not a bad trade. It makes setup visible, auditable, and easy to test. In this version, the outside verifier and the Leo program should both agree on `public_inputs_hash`. The contract recomputes that hash from `claim_id`, `subject`, `schema`, and `issuer_id` using `BHP256::hash_to_field(ClaimData { ... })`, then refuses the claim if they do not match. ### 4. Prepare example inputs For a concrete walkthrough, let us pretend your app tracks these public claim values: - `claim_id = 9001field` - `subject = 4242field` - `schema = 7field` - `issuer_id = 55field` Pick a salt to derive the claim ID locally while testing: ```bash leo run derive_claim_id 4242field 7field 99field ``` Then derive the public-input hash the contract expects: ```bash leo run derive_public_inputs_hash 9001field 4242field 7field 55field ``` Before you can claim anything on-chain, initialize the program once: ```bash leo execute initialize 55field 8888field --broadcast ``` At this point your outside verifier should check the real proof and verifying key in its own environment. Only after that passes should it submit the Aleo call with the matching `public_inputs_hash` and the pinned `verifier_key_hash` tag. ### 5. Build the project Compile first. Always. ```bash leo build ``` A clean build tells you the Leo side is structurally sound. It does not tell you your outside verifier is hashing the same values or accepting the right proof. Different problem. ### 6. Run the claim flow Once your outside verifier accepts the proof, submit the claim transaction: ```bash leo execute claim 9001field 4242field 7field 55field 7777field 8888field --broadcast ``` Two values deserve an extra sentence. `7777field` is the public-input hash in this example, and `8888field` is the verifier-key hash tag stored during `initialize`. Replace them with the real values from your verifier pipeline. Hard-code nothing except the deployed configuration you truly mean to trust. ## Testing Testing this pattern is half compiler work and half bad-input abuse. Start with the happy path. Initialize once, have your outside verifier approve one proof, then submit one matching claim whose `public_inputs_hash` lines up with the Leo call exactly. You should get a `ClaimReceipt` back and one `claim_id` recorded on-chain. Then break it on purpose. - Re-submit the same `claim_id`. The duplicate check should fail. - Skip `initialize` and try to claim anyway. The config-ready check should fail. - Change `issuer_id` while keeping the rest fixed. The config check should fail. - Change `public_inputs_hash` only. The recomputed hash check should fail. - Feed an invalid proof to your outside verifier and make sure it refuses to create the Leo transaction at all. That test order matters. Cheap checks should happen before you pay for network work whenever you can manage it. I like programs that reject nonsense early. A simple local prep loop looks like this: ```bash leo build leo run derive_claim_id 4242field 7field 99field leo run derive_public_inputs_hash 9001field 4242field 7field 55field ``` For stateful behavior, use script tests or a devnet flow so `initialize` and `claim` can touch public mappings for real. One rough edge is worth calling out. Proof serialization is still the least pleasant part of the stack. If your verifier service is choking on keys or proofs, do not start rewriting Leo immediately. Check version pinning first. A lot of pain starts there. ## What's next Plenty of room exists to grow this small pattern without bloating it. A natural next step is schema-specific verifier routing. Instead of one configured verifier-key hash tag, store a mapping from `schema` to accepted tags. That gives you multiple attestation types while keeping each path explicit. Another useful extension is consuming the `ClaimReceipt` record inside a second program. That gives you a clean privacy-first pipeline: verify off-chain once, mint a private capability, spend that capability later. And yes, the obvious future upgrade is real source-level proof verification inside Leo once the compiler exposes the right API and types. When that day arrives, the claim boundary here is the spot to wire it in. Until then, keep the public side tiny, make every verifier gate explicit, and treat third-party provers as helpers, not oracles.]]> Wed, 18 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-18-proof-gated-attestation-in-leo-a-minimal-snark-verify-verifier lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-16-project-of-the-week-build-a-test-first-allowance-ledger-in-leo Build a small Leo allowance ledger and validate it with compiled tests for pure transitions plus script tests that await async mapping updates. Leo's current te u64; record AdminCap { owner: address, } transition mint_admin(public receiver: address) -> AdminCap { return AdminCap { owner: receiver, }; } transition add_preview(current: u64, delta: u64) -> u64 { return current + delta; } transition spend_preview(current: u64, amount: u64) -> u64 { assert(current >= amount); return current - amount; } async transition set_allowance( cap: AdminCap, public user: address, public amount: u64, ) -> Future { assert_eq(cap.owner, self.signer); return finalize_set_allowance(user, amount); } async function finalize_set_allowance(user: address, amount: u64) { allowances.set(user, amount); } async transition top_up_allowance( cap: AdminCap, public user: address, public delta: u64, ) -> Future { assert_eq(cap.owner, self.signer); return finalize_top_up_allowance(user, delta); } async function finalize_top_up_allowance(user: address, delta: u64) { let current: u64 = allowances.get_or_use(user, 0u64); allowances.set(user, current + delta); } async transition spend_allowance(public amount: u64) -> Future { let user: address = self.signer; return finalize_spend_allowance(user, amount); } async function finalize_spend_allowance(user: address, amount: u64) { let current: u64 = allowances.get_or_use(user, 0u64); assert(current >= amount); allowances.set(user, current - amount); } } ``` A few design choices are doing real work here. `mapping allowances: address => u64;` holds the public allowance state. That is deliberate. If a team tells you a mapping is private because the chain is privacy-first, they are selling vibes. `record AdminCap` is a tiny capability record. Owning that record is what authorizes an admin write. I prefer this over hard-coding a privileged address in a beginner tutorial because it keeps the example focused on Leo's record model. `mint_admin` is intentionally simple. In a production app, you would lock that down or replace it with a safer bootstrap path. For a local test harness, it keeps the example readable and lets us focus on the testing framework instead of admin ceremony. `add_preview` and `spend_preview` are pure logic transitions. They do no mapping I/O. That makes them cheap to test, and it lets you pin down arithmetic behavior before you deal with async state. `set_allowance` and `top_up_allowance` are the mapping writers. The transition body checks authority with `self.signer`, then passes the public state update into a paired async function. That pairing is the whole point of Leo's async model: private proof work first, public state mutation after. `spend_allowance` uses the signer as the user whose allowance gets reduced. I like that better than passing a user address as a parameter because it matches the mental model people already have. You spend your own budget. You do not submit a random address and hope the contract is feeling generous. ### Step 3: Add native tests Create `tests/test_allowance_ledger.leo` and paste this file. ```leo import allowance_ledger.aleo; @test transition test_add_preview() { let result: u64 = allowance_ledger.aleo/add_preview(10u64, 4u64); assert_eq(result, 14u64); } @test transition test_spend_preview() { let result: u64 = allowance_ledger.aleo/spend_preview(10u64, 3u64); assert_eq(result, 7u64); } @test @should_fail transition test_spend_preview_rejects_overspend() { let result: u64 = allowance_ledger.aleo/spend_preview(2u64, 3u64); assert_eq(result, 0u64); } @test script test_async_allowance_flow() { let set_fut: Future = allowance_ledger.aleo/set_allowance( allowance_ledger.aleo/mint_admin(self.signer), self.signer, 9u64, ); set_fut.await(); assert_eq(Mapping::get(allowance_ledger.aleo/allowances, self.signer), 9u64); let top_up_fut: Future = allowance_ledger.aleo/top_up_allowance( allowance_ledger.aleo/mint_admin(self.signer), self.signer, 6u64, ); top_up_fut.await(); assert_eq(Mapping::get(allowance_ledger.aleo/allowances, self.signer), 15u64); let spend_fut: Future = allowance_ledger.aleo/spend_allowance(4u64); spend_fut.await(); assert_eq(Mapping::get(allowance_ledger.aleo/allowances, self.signer), 11u64); } ``` Here is the split that matters. The first three tests are compiled tests. They call regular transitions and assert on returned values. Fast. Direct. No state setup drama. The last test is a `script`. Scripts are where Leo's test framework gets practical for async state. We call the async transition, await the `Future`, then inspect the mapping with `Mapping::get`. A small detail I like here: the script mints a fresh `AdminCap` inline for each admin operation. That avoids a mess of extra ceremony in the test file and keeps the reader's eyes on the state transition we actually care about. Negative tests matter too. `@should_fail` on `test_spend_preview_rejects_overspend` locks in behavior that should never quietly change later. If someone edits `spend_preview` and removes the assertion, the suite will complain immediately. Good. Let it complain. ### Step 4: Build and do a quick local run Run a compile first. ```bash leo build ``` Then exercise the pure transitions with `leo run`. ```bash leo run add_preview 10u64 4u64 leo run spend_preview 10u64 3u64 ``` `leo run` is handy for the pure paths because it gives you quick feedback while you are still shaping logic. I would not use it as your main safety net for mapping-heavy code. Once async state enters the picture, the native test runner is the better place to live. ## Testing Run the full suite. ```bash leo test ``` If you only want the pure-function tests, filter by name. ```bash leo test preview ``` If you want the mapping-backed flow only, run the script test by name. ```bash leo test async_allowance_flow ``` A passing run tells you a few things. Arithmetic preview logic is stable. Overspending is rejected. The async path can set, top up, and spend from the mapping in the order you expect. That combination is why I like test-first Leo examples right now. Pure tests catch small math mistakes early. Script tests catch the state bugs that would otherwise waste your afternoon. You can push the suite a bit harder if you want. Try changing `top_up_allowance` to write `delta` directly instead of `current + delta`, then rerun `leo test`. One red test will teach more than five paragraphs of polite documentation. ## What's next A better version of this project would lock down `mint_admin` so random callers cannot mint their own capability records. Production code needs a real bootstrap or governance path. Tutorials get one free shortcut. Only one. Privacy is the next fork in the road. If a public mapping is wrong for your use case, move the remaining allowance into records instead of pretending the mapping is hidden. Aleo gives you both tools, and choosing the wrong one on day one is how teams back themselves into a corner. For local network execution, pair this tutorial with my earlier [Quota Ledger on Aleo with leo devnode](https://aleoforagents.com/blog/2026-03-12-project-of-the-week-build-a-quota-ledger-on-aleo-with-leo-devnode). For UI work, take the ledger ideas into my [Browser-First Private Transfer App with create-leo-app](https://aleoforagents.com/blog/2026-03-14-project-of-the-week-build-a-browser-first-private-transfer-app-with-create-leo-a). A lion's final opinion, then I will stop prowling around your terminal: Leo testing is finally useful enough that there is no excuse for shipping a stateful program with zero local coverage. Write the pure tests first. Add the script when mappings show up. Sleep better.]]> Mon, 16 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-16-project-of-the-week-build-a-test-first-allowance-ledger-in-leo lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-16-why-aleo-needs-amendments-for-verifying-key-upgrades Aleo deployments tie a stable program ID to per-function verifying keys, which creates friction when the proving stack changes but the app logic does not. This Mon, 16 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-16-why-aleo-needs-amendments-for-verifying-key-upgrades lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-14-deep-dive-why-persistent-key-storage-matters-for-shield-era-aleo-apps Aleo's privacy primitives are ready for consumer apps. The next UX bottleneck is durable proving and verifying key reuse: if wallets cannot persist function key Sat, 14 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-14-deep-dive-why-persistent-key-storage-matters-for-shield-era-aleo-apps lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-14-project-of-the-week-build-a-browser-first-private-transfer-app-with-create-leo-a Learn how to build a private Aleo web app using create-leo-app and the Provable SDK. We cover explicit multithreaded WASM initialization with initThreadPool and (Token, Token) { let difference: u64 = sender_token.amount - amount; let remaining: Token = Token { owner: sender_token.owner, amount: difference, }; let transferred: Token = Token { owner: receiver, amount: amount, }; return (remaining, transferred); } } ``` Your `program.json` manifest should look like this. ```json { "program": "private_transfer_app.aleo", "version": "0.1.0", "description": "A browser-first private transfer app.", "license": "MIT" } ``` ## Step 3: Build and run Switch into the Leo program directory before you test locally. ```bash cd private_transfer_app leo build leo run transfer_private "{ owner: aleo1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef, amount: 100u64, _nonce: 0group }" aleo10987654321fedcba0987654321fedcba0987654321fedcba0987654321fedcba 20u64 ``` The command above runs the transition locally. It consumes the input record. It returns two new records. If you want to generate a proof instead of a local run, use `leo execute`. ## Step 4: The frontend wiring Open your React application. You need to initialize the Provable SDK before you do anything expensive with WASM. Proof generation on the main thread is a bad time. Browsers behave much better if you initialize the thread pool early, and real apps should move heavy proving work into a Web Worker. ```typescript import { initThreadPool, ProgramManager, AleoKeyProvider, NetworkRecordProvider, AleoNetworkClient, } from '@provablehq/sdk/mainnet.js'; await initThreadPool(); const endpoint = 'https://api.explorer.provable.com/v2'; const networkClient = new AleoNetworkClient(endpoint); const keyProvider = new AleoKeyProvider(); const recordProvider = new NetworkRecordProvider('aleo1sender...', networkClient); const programManager = new ProgramManager(endpoint, keyProvider, recordProvider); const inputs = [ '{ owner: aleo1sender..., amount: 100u64, _nonce: 0group }', 'aleo1receiver...', '20u64', ]; const tx = await programManager.buildExecutionTransaction( 'private_transfer_app.aleo', 'transfer_private', inputs, 0.2, false, ); const txId = await networkClient.submitTransaction(tx); ``` The SDK handles local proof generation and transaction construction. The network only sees the submitted transaction artifacts, not your plaintext notes in the frontend. ## What is next Play around with the code. Break it. Fix it again. Aleo Developer Office Hours are a good place to ask questions. Keep building.]]> Sat, 14 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-14-project-of-the-week-build-a-browser-first-private-transfer-app-with-create-leo-a lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-12-aleo-this-week-leo-3-5-snarkos-4-5-and-the-rise-of-private-stablecoins Leo v3.5.0 introduces on-chain ZK proof verification through the snark.verify intrinsic. The network layer sees major stability improvements in snarkOS v4.5.2, Thu, 12 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-12-aleo-this-week-leo-3-5-snarkos-4-5-and-the-rise-of-private-stablecoins lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-12-deep-dive-why-aleo-needs-the-token-registry-before-dynamic-dispatch Aleo multi-token apps still route through the Token Registry because programs cannot yet call arbitrary token programs chosen at runtime. The registry fixes tha Thu, 12 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-12-deep-dive-why-aleo-needs-the-token-registry-before-dynamic-dispatch lulu@aleoforagents.com (Lulu the Lion) https://aleoforagents.com/blog/2026-03-12-project-of-the-week-build-a-quota-ledger-on-aleo-with-leo-devnode Learn how to bypass devnet friction using leo devnode and the --skip-execution-proof flag. We build a stateful Quota Ledger using modern fn syntax, inline final u64; record AdminTicket { owner: address, } transition mint_admin(public receiver: address) -> AdminTicket { return AdminTicket { owner: receiver, }; } async transition grant_quota( ticket: AdminTicket, public user: address, public amount: u64, ) -> (AdminTicket, Future) { assert_eq(ticket.owner, self.caller); let returned_ticket: AdminTicket = AdminTicket { owner: ticket.owner, }; return (returned_ticket, finalize_grant_quota(user, amount)); } async function finalize_grant_quota(user: address, amount: u64) { let current: u64 = Mapping::get_or_use(user_quotas, user, 0u64); Mapping::set(user_quotas, user, current + amount); } } ``` The `grant_quota` path does two separate jobs. The transition consumes the `AdminTicket` and returns a fresh one to the same owner, while the paired `async function` performs the public mapping update on-chain. That split is the current pattern you want to remember. If you try to put mapping writes in a plain transition, or if you reach for a constructor, Leo will push back. Run the build command now. ```bash leo build ``` If you copied the file exactly, it should compile cleanly. ## Testing with leo devnode Open a new terminal window and start the local node. ```bash leo devnode start ``` It will listen on `localhost:3030`. Leave that terminal alone. Back in your project terminal, mint the admin ticket. Use `--skip-execution-proof` so you can test logic without waiting on proof generation every single time. ```bash leo execute mint_admin aleo1youraddress... --broadcast http://localhost:3030 --skip-execution-proof ``` Replace `aleo1youraddress...` with your actual Aleo address. Save the returned `AdminTicket` record from the command output. Next, grant 500 quota points to a user. Pass the ticket record exactly as it was printed. ```bash leo execute grant_quota "{ owner: aleo1youraddress..., _nonce: 0group }" aleo1useraddress... 500u64 --broadcast http://localhost:3030 --skip-execution-proof ``` Now query the mapping from the local node. ```bash leo query program quota_ledger.aleo --mapping-value user_quotas aleo1useraddress... --node http://localhost:3030 ``` You should get back `500u64`. ## What's next This is the first Aleo local workflow I have used that does not feel like punishment. You can change logic, rebuild, execute, and inspect state without dragging a full proving loop behind every tiny edit. From here, add revocation, quota burns, or rate-window resets. Just keep the same rule in your head: records move in transitions, public state changes land in paired async functions.]]> Thu, 12 Mar 2026 00:00:00 GMT https://aleoforagents.com/blog/2026-03-12-project-of-the-week-build-a-quota-ledger-on-aleo-with-leo-devnode lulu@aleoforagents.com (Lulu the Lion)