DEV Community: CodeArchitect_J

approve, permit, transfer: what your wallet is actually asking you to sign #web3#security#ethereum#javascript

CodeArchitect_J — Fri, 06 Nov 2026 04:06:13 +0000

Most wallet drains don't break any cryptography. They get you to sign something you didn't read. Here's what the common prompts actually do.

transfer(to, amount)

Moves tokens out of your wallet right now. The risk is limited to that amount, and you can see it happen.

approve(spender, amount)

No tokens move now. You're allowing spender to pull up to amount later, as many times as it wants, until the allowance is used up or revoked. "Unlimited" approvals use the max uint256 value and never expire on their own.

permit (EIP-2612)

Same effect as approve, but it's an off-chain typed-data signature instead of a transaction. No gas, and nothing shows up in your transaction history when you sign it. Whoever holds that signature can submit it before the deadline. That's why phishing pages love it: "it's just a signature" sounds harmless.

Permit2

You approve the Permit2 contract once, then grant individual apps allowances by signature, usually with an amount and an expiry. Safer by design, but the same rule applies: read the spender, amount and expiry.

setApprovalForAll (NFTs)

Gives an operator control over every item you hold in that collection, not just one.

Decode before you trust the UI

If you're building or debugging, decode the calldata yourself instead of trusting a label:

import { Interface, MaxUint256 } from "ethers";

const erc20 = new Interface([
  "function transfer(address to, uint256 amount)",
  "function approve(address spender, uint256 amount)",
]);

const tx = erc20.parseTransaction({ data: calldata });
console.log(tx.name, tx.args);

if (tx.name === "approve" && tx.args[1] === MaxUint256) {
  console.warn("Unlimited approval to", tx.args[0]);
}

Five checks before you confirm

Which function: transfer, approve, permit, or something else?
Who is the spender or operator, and do you recognize that contract?
Is the amount unlimited?
Is there a deadline or expiry?
Is it the chain you expected?

If the prompt says "approve" or "permit" when you expected a simple swap or deposit, stop and find out why.

What's the most confusing signing prompt you've run into? Drop it below.

Ollama, llama.cpp or vLLM: pick by workload, not by benchmark Tags：llm, localllm, performance, ai

CodeArchitect_J — Wed, 04 Nov 2026 04:38:06 +0000

Every few weeks a new benchmark says one local inference stack is X% faster than another. The numbers are usually real. They're also usually answering a different question than the one you have. Here's how I choose, by workload.

One person, trying models → Ollama. If you're pulling a new model every few days to see how it behaves, setup time is the bottleneck, not tokens per second. Ollama's one-command pull and sensible defaults win here, and a slower decode rarely matters when you're reading the output yourself. One catch: set the context length explicitly. If you compare models on defaults, you're not comparing like with like.
One machine, squeeze it → llama.cpp. When the hardware is fixed (a single consumer GPU, a laptop with no discrete GPU, Apple Silicon) and you want every token per second, build llama.cpp yourself with the backend flags for your hardware. Generic prebuilt binaries often take conservative paths. You also get direct control over layer offloading, KV cache quantization and batch sizes.
Many users at once → vLLM. The moment several requests arrive concurrently, the question changes from "how fast is one answer" to "how many answers per GPU-hour". Continuous batching lets finished requests leave and new ones join mid-batch, and paged KV cache keeps memory from fragmenting. Single-user benchmarks don't show this at all. How to run a fair comparison • Same model file, same quantization • Same context length, set explicitly • Same prompts, including one long prompt (prefill) and one long answer (decode) • Measure time-to-first-token and decode tokens/s separately • Test at concurrency 1 and at your real expected concurrency • Write down driver, backend and build flags If two stacks only differ under one of these conditions, that's your real answer. Short version: Ollama optimizes your time. llama.cpp optimizes one machine. vLLM optimizes a shared GPU. Pick the one that matches what you're actually short of. What does your setup look like, and where did you see the biggest gap? Post your numbers with hardware and context length below.

What's your MCP server stack in late 2026?

CodeArchitect_J — Thu, 29 Oct 2026 05:27:01 +0000

I've been running a handful of MCP servers locally and remotely and I'm curious what others settled on. A few questions: stdio or HTTP transport in production? How do you scope which tools each agent can see? Any good patterns for budgets or rate limits on tool calls? And which servers turned out to be genuinely useful vs. demo-only? I'll share mine in the comments.

discuss #mcp #ai #opensource

What's your MCP server stack in late 2026?

CodeArchitect_J — Mon, 19 Oct 2026 09:48:45 +0000