Show HN: Verify-before-release x402 gateway for AI agent transactions https://ift.tt/uKWxIRG

Show HN: Verify-before-release x402 gateway for AI agent transactions Hey HN, I built Settld because I kept running into the same problem: AI agents can call APIs, pay for services, and hire other agents - but there's no way to prove the work was actually done before the money moves. The problem in one sentence: x402 tells you "payment was sent". Settld tells you "the work was worth paying for". What it does Settld sits between your agent and the APIs/agents it pays. It: 1. Intercepts HTTP 402 (Payment Required) responses 2. Creates an escrow hold instead of paying immediately 3. Collects evidence that the work was completed 4. Runs deterministic verification (same evidence + same terms = same payout, every time) 5. Releases payment only after verification passes 6. Issues a cryptographically verifiable receipt If verification fails or the work is disputed, the hold is refunded. The agent gets a receipt either way - a permanent, auditable record of what happened. Why this matters now We're at a weird inflection point. Coinbase shipped x402 (50M+ transactions). Google shipped A2A. Anthropic shipped MCP. Agents can discover each other, communicate, and pay each other. But nobody built the layer that answers: "was the work actually done correctly, and how much should the payout be?" That's the gap. Right now, every agent-to-agent transaction is either "trust and hope" or "don't transact." Neither scales. The x402 gateway (the fastest way to try it) We ship a drop-in reverse proxy that you put in front of any API: docker run -e UPSTREAM_URL= https://your-api.com \ -e SETTLD_API_URL= https://api.settld.dev \ -e SETTLD_API_KEY=sk_... \ -p 8402:8402 \ settld/x402-gateway Everything flows through normally - except 402 responses get intercepted, escrowed, verified, and settled. Your agent gets a receipt with a hash-chained proof of what happened. What's under the hood The settlement kernel is the interesting part (and where we spent most of our time): - Deterministic policy evaluation - machine-readable agreements with release rates based on verification status (green/amber/red). No ambiguity. - Hash-chained event log - every event in a settlement is chained with Ed25519 signatures. Tamper-evident, offline-verifiable. - Escrow with holdback windows - configurable holdback basis points + dispute windows. Funds auto-release if unchallenged. - Dispute → arbitration → verdict → adjustment - full dispute resolution pipeline, not just "flag for human review." - Append-only reputation events - every settlement produces a reputation event (approved, rejected, disputed, etc.). Agents build verifiable economic track records. - Compositional settlement - agents can delegate work to sub-agents with linked agreements. If a downstream agent fails, refunds cascade deterministically back up the chain. The whole protocol is spec'd with JSON schemas, conformance vectors, and a portable oracle: https://ift.tt/0YPr21W... What this is NOT - Not a payment processor - we don't move money. We decide "if" and "how much" money should move, then your existing rails (Stripe, x402, wire) execute it. - Not a blockchain - deterministic receipts and hash chains, but no consensus mechanism or token. Just cryptographic proofs. - Not an agent framework - we don't care if you use LangChain, CrewAI, AutoGen, or raw API calls. We're a protocol layer. Tech stack Node.js, PostgreSQL (or in-memory for dev), Ed25519 signatures, SHA-256 hashing, RFC 8785 canonical JSON. ~107 core modules, 494 tests passing. What I want from HN Honest feedback on whether this problem resonates. If you're building agent workflows that involve money, I want to know: what breaks? What's missing? What would make you actually install this? GitHub: https://ift.tt/xPfIy4A Docs: https://docs.settld.work/ Quickstart (10 min): https://docs.settld.work/quickstart February 14, 2026 at 01:17AM

Show HN: Skybolt Reflect – C++ header-only runtime reflection library https://ift.tt/plyQe6f

Show HN: Skybolt Reflect – C++ header-only runtime reflection library https://ift.tt/OEqmduC February 13, 2026 at 10:54PM

Show HN: Yori – Isolating AI Logic into "Semantic Containers" (Docker for Code) https://ift.tt/MLnOkcW

Show HN: Yori – Isolating AI Logic into "Semantic Containers" (Docker for Code) Hi HN, I've been a developer for some time now, and like many of you, I've been frustrated by the "All-or-Nothing" problem with AI coding tools. You ask an AI to fix a bug or implement a function, and it rewrites the whole file. It changes your imports, renames your variables, or deletes comments it deems unnecessary. It’s like giving a junior developer (like me) root access to your production server just to change a config file. So, 29 days ago, I started building Yori to solve the trust problem. The Concept: Semantic Containers Yori introduces a syntax that acts like a firewall for AI. You define a $${ ... }$$ block inside a text file. Outside the block (The Host): Your manual code, architecture, and structure. The AI cannot touch this. Inside the block (The Container): You write natural language intent. The AI can only generate code here. Example: myutils.md ```cpp EXPORT: "myfile.cpp" // My manual architecture - AI cannot change this #include "utils.h" void process_data() { // Container: The AI is sandboxed here, but inherits the rest of the file as context $${ Sort the incoming data vector using quicksort. Filter out negative numbers. Print the result. }$$ } EXPORT: END ``` How it works: Yori is a C++ wrapper that parses these files. Whatever is within the EXPORT block and outside the containers ($${ }$$) will be copied as it is. When you run `yori myutils.md -make -series`, it sends the prompts to a local (Ollama) or cloud LLM, generates the syntax, fills the blocks, and compiles the result using your native toolchain (GCC/Clang/Python). If compilation fails, it feeds the error back to the LLM in a retry loop (self-healing). Why I think this matters: 1. Safety: You stop giving AI "root access" to your files. 2. Intent as Source: The prompt stays in the file. If you want to port your logic from C++ to Rust, you keep the prompts and just change the compile target. 3. Incremental Builds (to be added soon): Named containers allow for caching. If the prompt hasn't changed, you don't pay for an API call. It’s open source (MIT), C++17, and works locally. I’d love feedback on the "Semantic Container" concept. Is this the abstraction layer we've been missing for AI coding? Let me hear your ideas. Also, if you can't run yori.exe tell what went wrong and we see how to fix it. I opened a github issue on this. I am also working in making documentation for the project (github wiki). So expect that soon. GitHub: https://ift.tt/rF5SvPb Thanks! February 13, 2026 at 01:17AM

Show HN: MicroGPT in 243 Lines – Demystifying the LLM Black Box https://ift.tt/RJKEVN5

Show HN: MicroGPT in 243 Lines – Demystifying the LLM Black Box The release of microgpt by Andrej Karpathy is a foundational moment for AI transparency. In exactly 243 lines of pure, dependency-free Python, Karpathy has implemented the complete GPT algorithm from scratch. As a PhD scholar investigating AI and Blockchain, I see this as the ultimate tool for moving beyond the "black box" narrative of Large Language Models (LLMs). The Architecture of Simplicity Unlike modern frameworks that hide complexity behind optimized CUDA kernels, microgpt exposes the raw mathematical machinery. The code implements: The Autograd Engine: A custom Value class that handles the recursive chain rule for backpropagation without any external libraries. GPT-2 Primitives: Atomic implementations of RMSNorm, Multi-head Attention, and MLP blocks, following the GPT-2 lineage with modernizations like ReLU. The Adam Optimizer: A pure Python version of the Adam optimizer, proving that the "magic" of training is just well-orchestrated calculus. The Shift to the Edge: Privacy, Latency, and Power For my doctoral research at Woxsen University, this codebase serves as a blueprint for the future of Edge AI. As we move away from centralized, massive server farms, the ability to run "atomic" LLMs directly on hardware is becoming a strategic necessity. Karpathy's implementation provides empirical clarity on how we can incorporate on-device MicroGPTs to solve three critical industry challenges: Better Latency: By eliminating the round-trip to the cloud, on-device models enable real-time inference. Understanding these 243 lines allows researchers to optimize the "atomic" core specifically for edge hardware constraints. Data Protection & Privacy: In a world where data is the new currency, processing information locally on the user's device ensures that sensitive inputs never leave the personal ecosystem, fundamentally aligning with modern data sovereignty standards. Mastering the Primitives: For Technical Product Managers, this project proves that "intelligence" doesn't require a dependency-heavy stack. We can now envision lightweight, specialized agents that are fast, private, and highly efficient. Karpathy’s work reminds us that to build the next generation of private, edge-native AI products, we must first master the fundamentals that fit on a single screen of code. The future is moving toward decentralized, on-device intelligence built on these very primitives. Link: https://ift.tt/KUntl2v February 12, 2026 at 11:38PM

Show HN: 3D and World Models for Consistent AI Filmmaking https://ift.tt/4JUmhkA

Show HN: 3D and World Models for Consistent AI Filmmaking I've been a photons-on-glass filmmaker for over ten years, and I've been developing ArtCraft for myself, my friends, and my colleagues. All of my film school friends have a lot of ambition, but the production pyramid doesn't allow individual talent to shine easily. 10,000 students go to film school, yet only a handful get to helm projects they want with full autonomy - and almost never at the blockbuster budget levels that would afford the creative vision they want. There's a lot of nepotism, too. AI is the personal computer moment for film. The DAW. One of my friends has done rotoscoping with live actors: https://www.youtube.com/watch?v=Tii9uF0nAx4 The Corridor folks show off a lot of creativity with this tech: https://www.youtube.com/watch?v=_9LX9HSQkWo https://www.youtube.com/watch?v=DSRrSO7QhXY https://www.youtube.com/watch?v=iq5JaG53dho We've been making silly shorts ourselves: https://www.youtube.com/watch?v=oqoCWdOwr2U https://www.youtube.com/watch?v=H4NFXGMuwpY The secret is that a lot of studios have been using AI for well over a year now. You just don't notice it, and they won't ever tell you because of the stigma. It's the "bad toupee fallacy" - you'll only notice it when it's bad, and they'll never tell you otherwise. Comfy is neat, but I work with folks that don't intuit node graphs and that either don't have graphics cards with adequate VRAM, or that can't manage Python dependencies. The foundation models are all pretty competitive, and they're becoming increasingly controllable - and that's the big thing - control. So I've been working on the UI/UX control layer. ArtCraft has 2D and 3D control surfaces, where the 3D portion can be used as a strong and intuitive ControlNet for "Image-to-Image" (I2I) and "Image-to-Video" (I2V) workflows. It's almost like a WYSIWYG, and I'm confident that this is the direction the tech will evolve for creative professionals rather than text-centric prompting. I've been frustrated with tools like Gimp and Blender for a while. I'm no UX/UI maestro, but I've never enjoyed complicated tools - especially complicated OSS tools. Commercial-grade tools are better. Figma is sublime. An IDE for creatives should be simple, magical, and powerful. ArtCraft lets you drag and drop from a variety of creative canvases and an asset drawer easily. It's fast and intuitive. Bouncing between text-to-image for quick prototyping, image editing, 3d gen, to 3d compositing is fluid. It feels like "crafting" rather than prompting or node graph wizardry. ArtCraft, being a desktop app, lets us log you into 3rd party compute providers. I'm a big proponent of using and integrating the models you subscribe to wherever you have them. This has let us integrate WorldLabs' Marble Gaussian Splats, for instance, and nobody else has done that. My plan is to add every provider over time, including generic API key-based compute providers like FAL and Replicate. I don't care if you pay for ArtCraft - I just want it to be useful. Two disclaimers: ArtCraft is "fair source" - I'd like to go the Cockroach DB route and eventually get funding, but keep the tool itself 100% source available for people to build and run for themselves. Obsidian, but with source code. If we got big, I'd spend a lot of time making movies. Right now ArtCraft is tied to a lightweight cloud service - I don't like this. It was a choice so I could reuse an old project and go fast, but I intend for this to work fully offline soon. All server code is in the monorepo, so you can run everything yourself. In the fullness of time, I do envision a portable OSS cloud for various AI tools to read/write to like a Github for assets, but that's just a distant idea right now. I've written about roadmap in the repo: I'd like to develop integrations for every compute provider, rewrite the frontend UI/UX in Bevy for a fully native client, and integrate local models too. https://ift.tt/O3t4Kdj February 11, 2026 at 11:40PM

Show HN: Double blind entropy using Drand for verifiably fair randomness https://ift.tt/mwbY3F0

Show HN: Double blind entropy using Drand for verifiably fair randomness The only way to get a trust-less random value is to have it distributed and time-locked three ways, player, server and a future-entropy. In the demo above, the moment you commit (Roll-Dice) a commit with the hash of a player secret is sent to the server and the server accepts that and sends back the hash of its secret back and the "future" drand round number at which the randomness will resolve. The future used in the demo is 10 secs When the reveal happens (after drand's particular round) all the secrets are revealed and the random number is generated using "player-seed:server-seed:drand-signature". All the verification is in Math, so truly trust-less, so: 1. Player-Seed should matches the player-hash committed 2. Server-Seed should matches the server-hash committed 3. Drand-Signature can is publicly not available at the time of commit and is available at the time of reveal. (Time-Locked) 4. Random number generated is deterministic after the event and unknown and unpredictably before the event. 5. No party can influence the final outcome, specially no "last-look" advantange for anyone. I think this should be used in all games, online lottery/gambling and other systems which want to be fair by design not by trust. https://ift.tt/MeiJjlu February 11, 2026 at 11:10PM

Show HN: I taught GPT-OSS-120B to see using Google Lens and OpenCV https://ift.tt/u7OXeod

Show HN: I taught GPT-OSS-120B to see using Google Lens and OpenCV I built an MCP server that gives any local LLM real Google search and now vision capabilities - no API keys needed. The latest feature: google_lens_detect uses OpenCV to find objects in an image, crops each one, and sends them to Google Lens for identification. GPT-OSS-120B, a text-only model with zero vision support, correctly identified an NVIDIA DGX Spark and a SanDisk USB drive from a desk photo. Also includes Google Search, News, Shopping, Scholar, Maps, Finance, Weather, Flights, Hotels, Translate, Images, Trends, and more. 17 tools total. Two commands: pip install noapi-google-search-mcp && playwright install chromium GitHub: https://ift.tt/0S7RIp3 PyPI: https://ift.tt/ehY469s Booyah! February 11, 2026 at 02:40AM