Alejandro Betancourt

Shipped a non-custodial escrow dApp: two parties who don't trust each other swap ERC20s in one atomic tx — full swap or nothing. First perfect grade of my master's (10/10). Solidity 0.8.28 · Foundry · OZ v5. Ethereum Sepolia. Demo: youtube.com/watch?v=A6CcRP…

A contract getter gives you current state — not history with timestamps. Built a server-side indexer that scans logs in windows from the deploy block (never block 0) and forces batchMaxCount:1 in ethers v6. Free-tier RPCs reject the default batching. Learned it the hard way.

E2E-testing a Web3 dApp without automating MetaMask: Inject a mocked window.ethereum — a real EIP-1193 provider backed by an ethers Wallet. Only the popup is faked; signing is real, on an ephemeral Anvil. Gotcha: wrap the signer in a NonceManager or two txs reuse a nonce.

Checks-Effects-Interactions as file structure, not just line order: Libraries only mutate state. The main contract owns the external calls Finalize state before the call → a reentrant call sees the op already closed Cleaner AND harder to exploit. Same decision #SmartContracts

Shipped a non-custodial escrow dApp: two parties who don't trust each other swap ERC20s in one atomic tx — full swap or nothing. First perfect grade of my master's (10/10). Solidity 0.8.28 · Foundry · OZ v5. Ethereum Sepolia. Demo: youtube.com/watch?v=A6CcRP…

@hieuvueth The post-quantum leg is the one people sleep on. Scaling and privacy get the attention, but "still secure when the assumptions shift" is the property that ages well. Hash-based security looks smarter every year

The more I learn about STARKs, the more convinced I am that they're much more than a scaling solution. Privacy. Integrity. Post-quantum security Starknet is building on a foundation designed for the long term.

@starkience Private governance — on-chain voting leaks weight and choices the moment the tally is public. Shielded ballots with a verifiable result would round out the set. Built a gasless DAO voting flow and public tallies were the obvious gap.

private: > transfers > lending > borrowing > staking > any ERC20 What are we missing? Name it and we'll do it 🤝

@rauchg Same wall from the audit side — running untrusted contract repos, a container with default caps is a speed bump, not a boundary. Dropped caps + egress filtering help, but microVM isolation is the only thing that actually contains a hostile process.

Kimi's paper underlines the importance of the right security boundary for agents to run in. tl:DR: container-level isolation is not enough. In their experiments, agents crashed the underlying machine (via kernel panics). Firecracker microVMs (as in Vercel Sandbox) are safe.

@BitgetWalletX Building on both sides of that — onchain payment flows in Solidity and MCP servers for agent tooling. Happy to connect.

Hello fellow developers/builders If you're building wallets, DeFi protocols, payment products, or autonomous agents, we'd love to connect. This is our official account of the Bitget Wallet eng team, and will be the official source of all developer updates, tech insights, and ecosystem integrations. We'll be sharing: - Engineering best practices and tech insights - Updates for API, SDK and dev tools - Success cases/Root cause analysis for integrations - Thoughts on onchain infrastructure We believe in helping developers connect onchain with better tools: Introducing: Bitget Wallet X Crypto is now multichain and AI-driven. Developers need simple and better ways to access onchain liquidity, market data, and infrastructure. Bitget Wallet X is Bitget Wallet's infrastructure stack for developers and enterprises. Through our Swap API and Market API, we provide wallets, DeFi protocols, aggregators, payment applications, solvers, and AI agents with a single point of access to essential onchain capabilities. Battle-tested and proven at scale: Our proprietary tech and integrated systems processed $56 billion in culminative trading volume, with daily volume peaking at $39 million, and a transaction success rate of 99.5%. Bitget Wallet X supports major ecosystems including Ethereum, Solana, BNB Chain, Base, Arbitrum, HyperCore, HyperEVM, Polygon, Avalanche, Morph, and Robinhood Chain. Successful partner integrations include @0xProject, @deBridge, @lifiprotocol, @CoWSwap, @VeloraDEX, and @symbiosis_fi. Our partners are already accessing better quotes, routing, and liquidity through Bitget Wallet X. We'll also share our work and thinking across security, multichain architecture, protocol integrations, and onchain infrastructure. We want to connect with more developers and partners, learning mutually as we explore a more open and efficient onchain infrastructure for the industry. Builders and Devs, let's connect!

@developer_dao @futexlabs Free calls matter less than the limits attached to them. Recently spent a week working around eth_getLogs caps that were different on every provider — block range, batch size, archive access. That's the number worth publishing.

What it feels like when you get those 1 million free RPC calls just for signing up for D_D Cloud ( @futexlabs )

@LotusFi_ Underwritable is a good bar. Worth noting the three pillars don't fail equally — code you can verify by reading it, economic design you can model, operational security is the one an outsider mostly has to take on trust.

Security at Lotus Lotus is built on the belief that onchain lending should be underwritable. That standard applies to the protocol itself. Our holistic security posture is built across three pillars: economic design, smart contracts, operational security

@gakonst Depends where you sit though — building MCP servers you still feel it, tool and resource definitions eat the window before the user types anything. The abstraction leaks the moment you're the one filling it.

remarkable how we no longer talk about context windows in day to day usage

@OpenZeppelin @Starknet @CairoLang AA doing the heavy lifting here — swapping the signature scheme without touching the protocol is the whole point. $0.06 for a Falcon-512 verify onchain is better than I'd have guessed. What does the path from experimental to audited look like for the verifiers?

Account abstraction lets Starknet accounts adopt post-quantum signatures in contract code, no protocol changes needed. Working with @Starknet, we built and deployed account contracts that verify Falcon-512 signatures, a NIST post-quantum standard, directly in @CairoLang.

@LiorGoldberg2 @ready__x Got it — signing stays trustless, privacy leans on the operator for now. Is client-side proof gen the roadmap, or too heavy for the Ledger UX?

Every account has two keys: the signing key and the viewing key. The signing key keeps your funds safe. It never leaves the Ledger device, so you have full custody. The viewing key is derived on your computer, and the operator generates the proof (for UX reasons). So today only self-custody is secured by Ledger.

Another step toward blockchain privacy: @ready__x now supports privacy for Ledger accounts

@FrancescoCiull4 Learning Rust myself right now — ownership still rewires my brain coming from Solidity/TS. Reminder set.

Today at 6 PM CEST, we’re going live to talk about one of my favorite topics in tech: Rust and Web Development. Set your reminder.

@dabit3 That self-updating fork loop is neat — the test suite basically becomes the reviewer. Whole thing holds only as far as coverage does.

Simple mental model for cloud agents: clone the exact state of your laptop, multiply it infinitely, and make it accessible via HTTP. Most people still don't know cloud agents can spin up full Linux, Windows, Android, etc.. environments on demand, run computer-use tests, record annotated video proof of your app working through updates, drive Playwright against live Chrome with persistent auth, all triggerable from anywhere. Here I'm experimenting with a fork of @NousResearch Hermes Agent built specifically on low latency. I've set up a @DevinAI automation that checks Hermes daily for upstream changes, implements the updates, runs tests to make sure it works, sends me proof that it does, creates a PR, and reviews it. All I have to do to keep the fork up to date is review the daily morning PR.

Where does nonReentrant go when your logic lives in libraries? Not on the library function. An internal lib inlines into the caller — no real boundary to guard and per-transfer guards leave gaps Guard the whole atomic operation: the orchestrator's checkout github.com/alebeta06/ecom…

@easeev @ChainstackHQ Good tip, will check Chainstack out. But like you said — the indexer's the real fix regardless of RPC. Client-side getLogs is always a stopgap. That's exactly where I landed.

@Ale_Beta Just use @ChainstackHQ — 100-block getLogs range on the free tier, 10k blocks on any paid plan, and batch requests that don't get rejected But using the indexer is the right way to go — with the right RPC under the hood!

Reading on-chain events from the frontend on free RPCs = a 4-error saga. Alchemy caps getLogs at 10 blocks. PublicNode blocks archive w/o a token. dRPC caps range at 10k + rejects batches >3. Fix: dual-RPC + batchMaxCount:1. Client-side getLogs doesn't scale. Use an indexer.

My invoices don't store whether they're paid. Checkout is atomic → if payment reverts, the whole invoice reverts with it. A half-paid invoice can't exist. So the invoice existing = it's paid. No paid flag to keep consistent. Less state, fewer invariants to break. #Solidity