Skip to content

Instantly share code, notes, and snippets.

@denniswon
denniswon / gist:876d96f073fa37adce99eb5a77886e0b
Created April 2, 2026 14:46
Newton Contract Deployment Infrastructure
---
★ Insight ─────────────────────────────────────
Article Context (getrecon.substack.com): The Recon article introduces safe-utils and tenderly-utils — Foundry libraries for
automating Safe multisig transaction proposals and Tenderly fork-based simulations. The key thesis: move governance/deployment
operations from manual UI clicks to reviewable, version-controlled Foundry scripts with pre-execution simulation. This is directly
relevant to Newton because we already have Foundry scripts but lack multisig governance and pre-deployment simulation infrastructure.
─────────────────────────────────────────────────
---
Deep Analysis: Newton Contract Deployment Infrastructure
@denniswon
denniswon / gist:4fc35b235596272c1692b0ea940de951
Created April 1, 2026 17:53
Newton Privacy Layer — Full Recall
---
Newton Privacy Layer — Full Recall
★ Insight ─────────────────────────────────────
The Privacy Layer follows a progressive decentralization strategy: centralized gateway decryption (Phase 1) → threshold DKG with
Feldman VSS/FROST (Phase 2) → MPC/ZK evaluation on encrypted data (Phase 3). The cryptographic stack bridges three incompatible
curves: BN254 (BLS attestation), X25519 (HPKE encryption), and Ristretto255 (FROST DKG) — connected by a single to_montgomery()
call at the combined DH output.
─────────────────────────────────────────────────
@denniswon
denniswon / gist:ad4d3d4879d967ee040286fb7e91a9c2
Created April 1, 2026 00:01
anthropics-claude-automation-recommender
❯ /anthropics-claude-automation-recommender
⏺ I'll analyze your Newton Prover AVS codebase to recommend the most valuable Claude Code automations.
Read 1 file (ctrl+o to expand)
⏺ Bash(ls Cargo.toml package.json 2>/dev/null; echo "---TOOLS---"; cat Makefile | head -30; echo "---HOOKS---"; cat
.claude/settings.json 2>/dev/null | python3 -c "imp…)
⎿  Error: Exit code 1
 Cargo.toml
@denniswon
denniswon / gist:c99a146e5f24eabd801a3f84a2acd348
Created March 29, 2026 23:30
Gateway: optimistic_insert_task only writes successful tasks
Now I see the full picture. There are two gaps:
Gap 1: optimistic_insert_task only writes successful tasks
Lines 42-49:
let task = match response.task.as_ref() {
Some(t) => t,
None => return Ok(()),
};
let task_response = match response.task_response.as_ref() {
@denniswon
denniswon / gist:f1fd0c07b48ad4c1908ae1e7cb0c5195
Created March 26, 2026 22:34
Plan: High-Throughput Batch Transaction Submission
❯ Load Test Report:
Configuration:
- Users: 10
- Spawn rate: 10 users/sec (all spawn immediately)
- Pacing: 15 seconds between requests per user
- Duration: 5 minutes
- Effective throughput: ~10 requests every 15 seconds (~40 req/min)
HTTP Layer — all 200 requests succeeded, median 2.8s, p95 3.5s
On-chain Submit (RPC → NewTaskCreated)
- 141/200 seen (70.5%)
@denniswon
denniswon / gist:d466df9c38324a9d4b3362bdd74604f7
Created March 25, 2026 17:08
transporter sync issue: initial startup sync failed, continuing with event loop
★ Insight ─────────────────────────────────────
0xc73a136a = InvalidGlobalTableRoot() — this is from the OperatorTableUpdater contract (EigenLayer's
IOperatorTableUpdater interface).
─────────────────────────────────────────────────
The transporter is calling confirmGlobalTableRoot on the destination chain's ECDSAOperatorTableUpdater (Base Sepolia
84532), and the contract is rejecting the Merkle root being submitted.
This typically means one of:
---
Newton Agent NeoBank — Project Status
Phase 0 — Completed
Phase 0 is fully built and deployed to Base Sepolia (stagef). Everything from the original scope shipped:
┌────────────────────────┬──────────────┬───────────────────────────────────────────────────────────────────────────┐
│ Component │ Status │ Key Evidence │
├────────────────────────┼──────────────┼───────────────────────────────────────────────────────────────────────────┤
Now I have the full picture. Here's the deep analysis:
The Architecture Problem
The commenter is pointing at a fundamental tension in the PRD's design. Let me map it out:
Current PRD Architecture (per-account policy storage)
Developer deploys PolicyClient contract (once)
└── Per user account:
@denniswon
denniswon / gist:80496d6d51674f21def9259d1b40c190
Created March 20, 2026 23:29
Private Data Storage Layer — Architecture Proposal
Looking at the Fireflies MCP setup, it's already configured in your system — I can see mcp__claude_ai_Fireflies__* tools are available in
the deferred tools list. That means Fireflies MCP is already connected via Claude's built-in MCP integration (managed by Anthropic), not a
self-hosted server.
Let me verify it's working:
⏺ Fireflies MCP is already set up and working. It's connected via Claude's built-in MCP integration (the mcp__claude_ai_Fireflies__ prefix
means it's a managed integration, not a self-hosted server). You have access to all 10 Fireflies tools:
┌─────────────────────────────────┬────────────────────────────────────────────────────────────────┐
@denniswon
denniswon / gist:3a69aa0a1860aba3060c7eb226e69e8a
Created March 20, 2026 11:53
Newton Protocol: Comprehensive Overview
---
Newton Protocol: Comprehensive Overview
Vision
Newton Protocol is the Authorization Layer for the Onchain Economy. Just as Visa authorizes payment transactions before settlement —
checking fraud rules, verifying identity, enforcing spend limits in real time — Newton authorizes onchain transactions against
programmable compliance and risk policies before they execute on any blockchain.
The key insight: Newton is not another regulator, not another Visa-like centralized entity. It is credibly neutral infrastructure that