标签：#Web

Debugging JWT authentication usually means copying tokens between tabs and tools. I built a free, browser-only JWT Creator & Signer — create, sign, and verify JWTs entirely in your browser using the Web Crypto API. Live Tool 👉 https://devnestio.pages.dev/jwt-creator/ What it does Create JWTs — edit header (alg, typ) and payload (any JSON) Sign with HMAC — HS256, HS384, or HS512 Quick claim buttons — insert sub , name , exp (+1h), iss with one click Generate random secrets — 256-bit hex secret via crypto.getRandomValues() Verify existing JWTs — paste any token and verify signature + expiry Color-coded output — header in red, payload in green, signature in blue 100% client-side — Web Crypto API, no server, your secrets stay local How signing works (Web Crypto API) const key = await crypto . subtle . importKey ( " raw " , new TextEncoder (). encode ( secret ), { name : " HMAC " , hash : " SHA-256 " }, false , [ " sign " ] ); const sig = await crypto . subtle . sign ( " HMAC " , key , new TextEncoder (). encode ( header + " . " + payload ) ); The output is base64url-encoded (replacing + → - , / → _ , stripping = padding) to form the final JWT. Why browser-only matters for a JWT tool JWT secrets are sensitive. Any tool that sends your signing secret to a server is a liability. This tool never sends anything — the Web Crypto API runs entirely inside your browser tab. Testing 77 tests, all passing ✅ Tests cover: Base64url encoding edge cases JWT structure (3-part dot-separated) HMAC algorithm mapping (HS256 → SHA-256 etc.) Expiry check (expired vs. valid tokens) Error states: invalid JSON payload, malformed JWT UI: claim insertion, secret toggle, copy, clear Web Crypto API usage verification All tools at devnestio.pages.dev — free browser-only developer utilities. Feedback welcome!

As a final-year Software Engineering student, I wanted my Final Year Project to be more than just another CRUD application. That's how Invesmal came to life a Laravel-based platform that connects startups, investors, and mentors using AI-driven matching. The Problem Finding the right investor or mentor is hard. Startups struggle to identify investors whose interests align with their industry, while investors sift through hundreds of pitches manually. I wanted to solve this with smart, automated matching instead of a simple directory listing. What Invesmal Does Invesmal supports four user roles Student, Investor, Mentor, and Admin and includes 12 AI-driven features built on top of a Laravel backend, including: A core matching engine connecting startups with relevant investors Skills and personality analysis for founders Goal-based matching between mentors and mentees Compatibility scoring between startups and investors A funding readiness score to evaluate startup preparedness A startup health score for ongoing progress tracking A recommendation engine surfacing relevant connections Each feature is built as an independent service class connected through dedicated controllers and routes, keeping the codebase modular and easy to extend. Technical Approach The platform is built entirely on Laravel , using: Service-oriented architecture for AI features (separating business logic from controllers) Blade components for dynamic role-based dashboards Livewire for real-time, reactive UI elements without heavy JavaScript A structured chat/messaging system for communication between users One of the more interesting engineering challenges was migrating a working chat and messaging system from an older version of the project into a redesigned Laravel structure while preserving functionality and fixing layout issues (like a tricky sidebar CSS opacity bug) along the way. What I Learned Building Invesmal taught me how to: Structure a large, multi-role Laravel application without the

AI is great at writing tests fast, and good at writing tests that look real but verify the wrong...

AI is great at writing tests fast, and good at writing tests that look real but verify the wrong...

Building an AI agent is fun. Fixing its production latency when it's juggling live data, RAG, and text-to-speech? Not so fun. In the latest episode of the AI Agent Clinic, we sat down with developer Sami Maghnaoui to debug PlaybackIQ, a football / soccer agent he built to provide pre and post match analysis with text to voice, and minute-by-minute match insights with interactive UI. The app was awesome, but under heavy "match day" data loads, the wait times were killing the UX. Here’s how we fixed it: The Bottleneck: We implemented OpenTelemetry on the Agent Platform to trace exactly where the LLM calls and data retrieval were hanging up. The Scale: We shifted the deployment to Cloud Run to properly handle concurrent traffic. The Result: We managed to slash the agent's latency by 80%. If you're dealing with sluggish LLM response times in your own apps and want to see what a production-grade fix looks like, we recorded the whole teardown and rebuild. 🎥 Watch the teardown here: [ https://youtu.be/G7olcqETSn8 ] (Let me know in the comments what your go-to stack is for tracing LLM latency!)

The problem no one was solving Every Algerian developer building with AI hits the same wall: an international payment card. OpenAI, Anthropic, Google — every major AI provider assumes you have one. Most Algerian developers don't, or don't want to deal with the friction of currency conversion, card rejections, and unpredictable billing in a foreign currency. That's not a minor inconvenience. It's a barrier that quietly excludes an entire generation of developers from building with the best AI models available — not because they lack the skill, but because of infrastructure that was never designed with them in mind. The vision: AI sovereignty, not just AI access Access alone isn't the goal. The goal is sovereignty — Algeria having its own AI infrastructure layer, controlled locally, billed locally, and built to local compliance standards, instead of depending entirely on foreign gateways with no local accountability. That's what DEVUP AI is: Algeria's first AI inference gateway, built from the ground up to remove every friction point between an Algerian developer and the AI models they need. What DEVUP AI actually does 170+ AI models — including DeepSeek V4, Llama 3.1 405B, Qwen 3, Gemma 2, Mistral, GPT, Claude, and Gemini — through a single API OpenAI-compatible and Anthropic-compatible — point your existing SDK at our endpoint, no code rewrite needed Local DZD billing via Edahabia/CIB — no international card required SATIM-certified payment infrastructure — full compliance with Algeria's national payment standards Scoped JWT authentication for production-grade security A dedicated SDK ( npm install devupai ) and full documentation, so integration takes minutes, not days The technical bar was non-negotiable: this had to be production-grade from day one, not a side project. SATIM certification alone meant building proper transaction validation, receipt generation, chargeback tracking, and rejection-rate monitoring — the same rigor a bank would expect from a payment pr

Every data grid demo looks incredible with twenty rows. The columns line up. The hover state is tasteful. The checkbox has confidence. Someone scrolls three inches and everyone quietly agrees that software has advanced. Then the real product arrives. Fifty thousand rows. Twenty columns. Editable money. A custom status cell. Filters. Sorting. Horizontal scrolling. A user who pastes something suspicious from Excel. A product manager asking whether the total row can stay pinned while the server is slow. That is when a table stops being a table and starts becoming infrastructure. So we built a benchmark. Not a perfect benchmark. Those do not exist. A useful one. What we measured The fixture is intentionally boring: 50,000 deterministic rows 20 fixed-width columns 1,200 by 600 pixel viewport two editable columns sorting filtering virtual scrolling production bundles fresh browser contexts raw samples committed to GitHub No network requests. No paid-only feature tricks. No images. No grouping. No heroic demo code designed to make one library look blessed by destiny. The report measures: JS gzip : reachable JavaScript after gzip Ready median : navigation until the grid adapter mounts and two animation frames pass Scroll settle : one scripted vertical and horizontal jump plus animation frames Mounted cells : body cells in the DOM after the scroll Interaction health : heap, long tasks, estimated FPS, dropped frames Live benchmark: https://vitashev.github.io/react-data-grid-benchmark/ Source and raw samples: https://github.com/Vitashev/react-data-grid-benchmark The part most benchmarks get wrong Not every grid exposes the same surface. For example, MUI X Data Grid Community uses 100-row pagination for this workload. That is a valid product boundary, but it is not the same as continuously virtualizing 50,000 rows. So the ranked tables include only compatible continuous-scroll libraries. MUI remains in the fixture and raw data, but not in the leaderboard. That makes the benchma

Key Takeaways You can't unit-test a coach agent the way you test a pure function — the output is non-deterministic and "good" is a judgment call, not an assertion. An LLM-as-judge harness lets you grade a whole test set automatically against a rubric, which is the only way solo-scale eval stays sustainable. But the judge is itself a fallible model. If you don't design around its known biases — position, verbosity, self-preference, and quiet drift when the judge model updates — you build a green dashboard that means nothing. The mitigations that actually work are mechanical, not prompt-magic: shuffle order on every pairwise call, pin the judge version, keep a small human-labelled anchor set, and re-check the judge against it. The problem I actually had FamNest's coach agent generates responses to parents — check-ins, encouragement, the occasional gentle redirect. I have a growing pile of these interactions, and every time I change a prompt, swap a model, or adjust the pipeline, I need to know one thing: did I just make it better or worse? For normal code, that's what tests are for. I change something, the suite runs, red or green, done. But there's no assertEqual for "was this an empathetic, useful response to a tired parent." The output changes every run even at temperature zero-ish, and the quality bar is a human judgment, not a fixed string. Two responses can be worded completely differently and both be good. One can match my "expected output" word for word and still be worse than a version that didn't. So the honest options were: read every response by hand every time I change something (does not scale past about week two), or build a harness where a model grades the outputs against a rubric. I built the harness. Then I spent an uncomfortable amount of time learning all the ways a harness like that can lie to you. What the harness actually is At its simplest, it's a loop: def evaluate ( test_cases , coach_agent , judge ): results = [] for case in test_cases : res

A few weeks ago I was in Copenhagen for my first Codegarden, and one quiet thought has stuck with me since. It didn't come from a keynote. It came from the bit the keynote leaves out. I've worked with Umbraco for years, but I'd never been to Codegarden, and I turned up without much of a fixed idea of what the two days would be. I kept that open on purpose. I wanted to take it in rather than measure it against something I'd decided in advance. What struck me most was that the value came from two places at once. The sessions were a fantastic source of inspiration; everything from keynotes to guest speakers all seemed to resonate in some way or another. The conversations in between the sessions - drifting around the event space and finding common ground with anyone and everyone - proved just as valuable. I came home more energised than I've been in a while, with a notebook full of half-formed ideas and a better feel for the community I'm part of. But the thing I kept turning over afterwards was that bit the keynote leaves out. That's what I want to write about. The easy half and the hard half Every major Umbraco release gets the same treatment. A polished keynote, a clean demo, a feature that looks effortless on stage. There's plenty in 18, and which part matters most depends on what you're building. For me it's Elements: a new Library section where you manage reusable content and reference it through a new element picker. Create once, use everywhere. It's a genuinely good direction. Reusable content has lived awkwardly in the content tree for years, and Library finally gives it a proper home. What the demos don't show you is the part I've been playing around with for the past few weeks. Taking a real Umbraco 17 site, with content pickers threaded through block lists, block grids, rich text blocks and base document properties, and getting all of it to point at the new Library without an editor ever noticing anything moved underneath them. The feature is the easy half.

For years I copied cron expressions off Stack Overflow, pasted them into a config file, crossed my fingers, and moved on. 0 9 * * 1-5 ? Sure, that "looks like weekday morning." */15 * * * * ? "Every 15 minutes, probably." I never actually read them. So I did the thing that always cures this for me: I built a tool that parses a cron expression, explains it in plain English, and shows the next five times it will fire. No library. About 50 lines of real logic. Here's everything I learned. The five fields (and the order that trips everyone up) A standard cron expression is exactly five fields separated by spaces: ┌──────── minute 0 - 59 │ ┌────── hour 0 - 23 │ │ ┌──── day - of - month 1 - 31 │ │ │ ┌── month 1 - 12 │ │ │ │ ┌ day - of - week 0 - 6 ( 0 = Sunday ) * * * * * The order never changes, and the number-one beginner mistake is swapping the first two. Minute comes first. If you write 9 30 * * * thinking "9:30am," you actually get "minute 9, hour 30" — which is invalid, because hours only go to 23. Say it out loud every time: minute, hour, day-of-month, month, day-of-week. Each field answers one question: which values of this unit does the job run on? An * means "every value." Most real schedules pin down a couple of fields and leave the rest as * . Daily at 9am is 0 9 * * * — minute and hour fixed, everything else "every." Lists, ranges, and steps Beyond single numbers, each field understands three operators, and they combine: Comma makes a list: 1,15 in the day field means the 1st and the 15th. Hyphen makes an inclusive range: 1-5 in the day-of-week field means Monday through Friday. Slash makes a step, taking every n-th value: */15 in the minute field means 0, 15, 30, 45 . Steps can apply to a range too, so 0-30/10 means 0, 10, 20, 30 . That's the whole grammar. Number, list, range, step. Once you can expand a field into the concrete set of numbers it matches, you understand cron. Here's the expansion function, which is the heart of the parser: function expandFie

By the team at MailTester Ninja — a real-time email verification API that stores nothing. We verify a lot of email for a living. So we pointed our infrastructure at a representative panel of 50,000 of the world's most-linked domains and measured how email is actually configured in 2026 — MX providers, SPF and DMARC. Pure DNS, aggregate only, no personal data . Here's what the internet's mail setup looks like right now. Email is still (almost) everywhere 79.9% of these domains are mail-enabled (they publish MX records). Email isn't going anywhere. Authentication: adopted, but not enforced 75.8% publish an SPF record 64% publish a DMARC record …but only 22.6% actually enforce it with p=reject That last number is the real story. Of the domains that bother to publish DMARC, only 35.2% are on p=reject — the rest sit on p=none (37.2%, monitoring only) or quarantine (27.6%). Most of the web announces a policy it doesn't enforce. That's a deliverability and spoofing gap hiding in plain sight. Who runs the world's inboxes? Other / self-hosted — 32.6% Google Workspace / Gmail — 28.2% Microsoft 365 / Outlook — 22.5% Proofpoint — 5.5% Mimecast — 3.1% Tencent QQ — 2% Namecheap — 1.3% Cisco IronPort — 0.9% Self-hosted and the two hyperscalers (Google Workspace and Microsoft 365) dominate, but the long tail of providers is very real — which is exactly why deliverability is hard: every provider blocks, greylists and reputation-scores differently. Why we publish this We built an open, daily-updated dataset and a live dashboard because deliverability decisions should be based on data, not folklore. It's CC BY 4.0 — use it, cite it, build on it. Want to check a specific domain? Our free analyzer shows any domain's MX / SPF / DMARC in one click — no signup, nothing stored. Methodology: Live DNS scan (MX/SPF/DMARC). Aggregate only — no email sent, no personal data. Sample updated Wed, 01 Jul 2026 12:31:00 GMT.

Let’s face it: if your current frontend optimization strategy still involves manually auditing codebases for missing useMemo hooks, micro-managing dependency arrays, or aggressively fighting layout shifts with complex client-side state management, you are wasting your engineering leverage. As we cross the midpoint of 2026, web framework architecture has quietly undergone a massive shift. We have firmly moved out of the era of manual performance tweaking and entered the era of automated, compile-time optimization . The goal of modern development is no longer just shipping fewer kilobytes to human users—it's also about optimizing data chunk delivery for AI web crawlers that evaluate your site in real-time. Here is how the modern full-stack ecosystem redefined performance this year, and what you should focus on instead. 1. The Death of Manual Memoization (Thanks, React Compiler) For years, React developers bore the cognitive load of rendering performance. One misplaced reference and your entire component tree re-rendered down to the root. With the absolute maturity and default adoption of the React Compiler across production frameworks, that paradigm is officially legacy code. The compiler handles component memoization automatically at the build step by analyzing javascript structures directly. // ❌ THE OLD WAY (Pre-2026 Manual Overhead) const ExpensiveComponent = memo (({ data }) => { const processedData = useMemo (() => computeHeavyMetrics ( data ), [ data ]); const handleAction = useCallback (() => { ... }, []); return < DataGrid items = " {processedData} " onAction = " {handleAction} " /> ; }); // THE MODERN WAY (Zero Performance Boilerplate) export function ModernComponent ({ data }) { const processedData = computeHeavyMetrics ( data ); const handleAction = () => { ... }; return < DataGrid items = " {processedData} " onAction = " {handleAction} " /> ; } Because the compiler injects optimization markers directly into the output code, human engineers can stop arguin

HeroUI v3 is a redesigned React component library, previously NextUI, offering over 75 components, including 21 new ones, and a new React Native library with 37 components. Built on React Aria and Tailwind CSS v4, it emphasizes accessibility and customization. The library has experienced many updates since its release, and migration from the previous version is necessary. By Daniel Curtis

Seriously, LeetCode in 2026? Everyone is saying HackerRank just killed LeetCode, and yet here I am,...

While researching the massive wave of digital transformation rewriting the rules for startups this year, I stumbled upon an insightful podcast by the tech firm GeekyAnts. Hosted by Prem, the episode featured Sanket Sahu, the co-founder of GeekyAnts, who recently emerged from a year and a half hiatus to discuss what he calls the " AI-native shift ." As someone navigating the unpredictable US tech market in 2026, listening to their conversation felt like a reality check. We are constantly flooded with news about AI replacing engineers or cutting budgets, but this discussion offered a grounded perspective on what is actually happening on the ground in software development. The Illusion of Speed The central theme that caught my attention was the sheer velocity of modern AI adoption. Sanket made a striking contrast: while television took decades to become a common household utility, modern AI systems like ChatGPT or Claude reached exponential revenue and widespread adoption in mere months. But here is where the critical analysis kicks in. As founders, we often mistake engineering speed for product success. The podcast highlighted a massive bottleneck that many of us are guilty of overlooking: the human limit. While AI can spin up code in hours instead of months, the time required for human review, validation, and team collaboration remains relatively static. If an organization rushes to ship code simply because it can, they risk launching products that lack deep market validation. True product development still requires user testing and meticulous iteration. The building phase might be operating at 10x speed, but the surrounding human infrastructure is only moving at 1.5x. Fluid Roles and the Rise of the "Builder" Another significant takeaway for Western businesses is the shifting definition of software roles. The traditional silos dividing front-end, back-end, and DevOps are rapidly blurring. According to the insights shared in the video, the engineering ecosystem is mo

CalcMora just crossed 200 live tools calculators and converters spanning finance, health, math, unit conversions, date/time, everyday life, and sports. It's a small milestone against the bigger target (3,000 tools within a year), but it's the first one that felt like proof the approach actually works. What CalcMora is A free calculator and converter site, built to be fast and genuinely useful rather than bloated with unnecessary interactivity. Every tool lives on its own page, static by default, ad-supported, and designed to actually rank and hold up in search rather than just exist. The stack is intentionally boring: Astro for static output, hosted on Cloudflare Pages . No client-side framework runtime, no heavy JS bundles. That choice is mostly why the site stays fast even as the tool count climbs into the hundreds; static pages don't get slower just because there are more of them. Consistency at scale Going from a handful of tools to 200 forced us to think hard about repeatability. Every tool page follows the same underlying template: a calculator, supporting explanatory content, an FAQ section, and standard trust/attribution elements (author info, last-updated date, disclaimers where relevant). That consistency is what makes it realistic to keep scaling toward thousands of pages without every single one needing a bespoke pass. Structured data (schema.org markup) is baked into every page too; it's a big part of why individual calculators show up well in search, and it's applied consistently rather than as an afterthought. New: embeddable tools The other big addition alongside the 200-tool mark is an embed system — every tool on CalcMora can now be dropped into someone else's site as a lightweight, ad-free widget. Site owners get a copy-paste snippet, no signup required. The implementation leans on a couple of iframe and query-param tricks to keep embedded calculators fast and chrome-free (no header, footer, or ads, just the tool), without needing any JS framework

Here's an uncomfortable truth nobody wants to admit out loud: most teams can generate a working app in minutes now, but almost none of them can ship it to production without breaking something important. Only a small fraction of organizations have actually moved their AI-built systems past the pilot stage. The gap between "it works on my machine" and "it works for real users" has never been wider, and closing that gap is quickly becoming the single most valuable skill a developer can have this year. If you have been prompting your way to a working prototype and then hitting a wall when it's time to actually deploy, this guide walks through exactly how to close that gap, with working examples at every step. Why This Matters Right Now Vibe coding, meaning describing what you want in plain language and letting an AI model scaffold the implementation, has gone from a novelty to a default workflow. Developers are shipping REST APIs , auth flows, and full CRUD apps with a single well-written prompt. But speed of generation is not the same as readiness for production. Untested edge cases, missing validation, weak error handling, and security gaps show up constantly in AI-generated code because the model optimized for "looks correct" rather than "survives real traffic." The developers who stand out this year are not the ones who can generate code fastest. They are the ones who know how to validate it, harden it, and integrate it responsibly. Below is a practical checklist you can apply to any AI-generated codebase before it touches a real user. Step 1: Treat the AI Output as a First Draft, Not a Final Answer Say your AI assistant generates this login handler: \ javascript // AI-generated first draft app.post('/login', async (req, res) => { const { email, password } = req.body; const user = await db.query( SELECT * FROM users WHERE email = '${email}' ); if (user.password === password) { res.json({ token: generateToken(user) }); } }); \ \ Looks functional. It is also a SQL in

The Subscription Fatigue is Real I was paying $47 for ChatGPT Plus, $29 for Jasper, $19 for Grammarly, $16 for Copy.ai, and $15 for an SEO tool. That's $126/month just for AI writing tools. So I built my own. Five tools, one dashboard, completely free to start. Here's how each one works and what it replaces. 1. AI Content Writer (Replaces Jasper, Copy.ai — $66/month combined) The content writer generates blog posts, articles, product descriptions, and marketing copy. You pick: Content type : blog post, article, product description, marketing copy, newsletter Tone : professional, casual, friendly, authoritative, humorous, persuasive Length : short (100-200 words), medium (300-500 words), or long (800-1200 words) The key difference from Jasper: no templates, no "brand voice" setup. You just describe what you want and get it. Simpler, faster. 2. AI Email Composer (Replaces Grammarly Business — $16/month) This one handles the emails I hate writing: Cold outreach to potential clients Follow-up emails after meetings Professional inquiries Customer support replies You set the formality level (formal, semi-formal, casual) and urgency. It writes the subject line AND the body. I've used it for 50+ cold emails last month. 3. Social Media Caption Generator (Replaces Later + caption tools — $29/month) Generates 3 caption variations per request. Platform-specific: Instagram : emojis, hashtags, engagement hooks Twitter/X : concise, thread-ready LinkedIn : professional, thought-leadership style TikTok : casual, trend-aware Options for emojis, hashtags, and CTAs are toggleable. You can mix and match from the 3 generated options. 4. AI Code Helper (Replaces GitHub Copilot Chat — $10/month) Five modes: Generate : write code from description Debug : find and fix errors in pasted code Explain : break down complex code Refactor : improve code quality Convert : translate between 20+ languages Supports Python, JavaScript, TypeScript, Java, C++, Go, Rust, SQL, and more. Not as deeply integr

The Token Bucket Algorithm: Server-Side API Rate Limiting in ~40 Lines Plenty of tutorials teach you how to survive someone else's rate limit with retries and backoff. Far fewer show you how to build one. If you run an API, you need rate limiting on your side too — to protect your database from a runaway client, keep one noisy tenant from starving everyone else, and give abusive traffic a polite 429 instead of a melted server. The cleanest algorithm for the job is the token bucket . Let's implement it from scratch, then make it production-ready. How token bucket works Picture a bucket that holds up to capacity tokens. Every request removes one token. The bucket refills at a steady refillRate (tokens per second), up to its cap. If a request arrives and the bucket is empty, it's rejected. This gives you two useful properties at once: A sustained rate — the long-run average, set by refillRate . A burst allowance — clients can spend the whole bucket at once, set by capacity . That burst tolerance is why token bucket feels fair. A user who's been quiet for a minute can fire off a batch of requests without being punished for it. A minimal implementation Here's a self-contained bucket in JavaScript. No dependencies, no timers — we compute refill lazily based on elapsed time, which is both simpler and more accurate than a background interval. class TokenBucket { constructor ( capacity , refillRatePerSec ) { this . capacity = capacity ; this . refillRate = refillRatePerSec ; this . tokens = capacity ; this . lastRefill = Date . now (); } _refill () { const now = Date . now (); const elapsedSec = ( now - this . lastRefill ) / 1000 ; this . tokens = Math . min ( this . capacity , this . tokens + elapsedSec * this . refillRate ); this . lastRefill = now ; } take ( cost = 1 ) { this . _refill (); if ( this . tokens >= cost ) { this . tokens -= cost ; return { ok : true , remaining : Math . floor ( this . tokens ) }; } const deficit = cost - this . tokens ; const retryAfter = Mat

Written from months of grinding on shielded liquidity DeFi protocols on Midnight. If you've been trying to build anything serious with shielded fungible tokens on Midnight lending protocols, liquidity pools, DEXes you've probably hit some walls that the documentation doesn't fully prepare you for. The Midnight programming model around shielded tokens is genuinely different from anything in the EVM world, and a lot of the intuitions you carry from Solidity or even other ZK environments will get you into trouble fast. This post is a breakdown of the most impactful errors and misconceptions I ran into while building shielded liquidity DeFi contracts using Midnight's Compact language. These are not theoretical every single one of these either broke a circuit or caused a proof server failure at some point. I'll walk through what the issue is, why it happens, and what the correct pattern looks like. Background: How Shielded Tokens Actually Work Under the Hood Before we get into the errors, let's get clear on the underlying mechanics because this context is what makes the errors make sense. Midnight uses a protocol called Zswap for shielded token operations. When a user sends tokens to your contract by calling receiveShielded , what actually happens is more involved than it looks on the surface. When your circuit calls receiveShielded(coin) , the Compact runtime records a shielded receive obligation in the transaction being constructed. At this point, the proof server kicks in to generate the ZK proof for your circuit. But here's the thing your circuit only describes what the contract side is doing. The transaction still needs to be balanced : the tokens being received by the contract have to come from somewhere. This is where the wallet gets involved through an internal mechanism that runs beneath your circuit. The wallet looks at the ShieldedCoinInfo you're receiving the coin's color (token type) and value and finds a matching UTXO in the user's private coin set. It then