LAST MOON

i have a habit when i see technical terminology i don't fully understand — i don't move on until i find the analogy that makes it click. jargon is usually just a familiar concept wearing unfamiliar clothes
zkPermissions showed up in everything i read about Newton Protocol. zero-knowledge circuits, programmable constraints, scoped delegation. okay. but what is it actually
i went looking for the plain language version and found it in Newton's own documentation. one sentence that reframed everything
"through zkPermissions, users define what agents can and cannot do — similar to how OAuth controls access in traditional web applications"
OAuth. that's the one 👀
if you've ever clicked "sign in with Google" you already understand the problem zkPermissions is solving
OAuth is the web standard that lets you give an app access to your Google account without giving it your password. instead of handing over your credentials, you grant a scoped permission — this app can read your email but not send it, can see your calendar but not delete it. the permission is specific, limited, and revocable
before OAuth existed, the alternative was giving every app your actual password and trusting them not to misuse it. which is insane in retrospect. but that's exactly where crypto is right now with automated agents
if you want an AI agent to manage your DeFi positions, the current alternative in most systems is giving it your private key. which is the equivalent of giving an app your Google password and hoping for the best
zkPermissions is Newton's answer to that problem. instead of giving an agent your private key, you issue a permission — this agent can execute trades but only when volatility is below X, can rebalance but only up to Y% of the portfolio, can interact with these protocols but not those ones. the permission is cryptographically enforced, not just trusted
where zkPermissions goes beyond what OAuth ever could
here's the part that actually surprised me when i dug deeper
OAuth works because you trust Google to enforce the permission boundaries. the app doesn't get access beyond what Google's server allows. that trust in the central authority is what makes OAuth work — and it's also its fundamental weakness. if Google's OAuth server has a bug, or gets compromised, or changes its policy, the permissions stop meaning what you thought they meant
zkPermissions doesn't work through a trusted server. it works through zero-knowledge circuits — cryptographic constraints that are mathematically enforced rather than policy enforced
the difference: with OAuth, the boundary is "the server won't let the app exceed this scope." with zkPermissions, the boundary is "it is cryptographically impossible for the agent to exceed this scope"
not "we trust Newton not to let the agent do something outside its permission." not possible at all given the math
that's a fundamentally different trust model. the constraint doesn't live in a server policy. it lives in the proof itself 🧐
the specific conditions zkPermissions can encode
from Newton's documentation, zkPermissions support:
data-driven execution conditions — "only act when this price feed shows X"
risk sensitivity checks — "stop if volatility exceeds Y"
transaction volume limits — "never move more than Z in a single transaction"
timing restrictions — "only execute between these hours"
protocol restrictions — "interact with these contracts, not those"
and critically, every session key — the thing that actually lets an agent act on your behalf — is bound to a zkPermission. not referenced by a permission. bound. the session key literally cannot be used outside the constraints the zkPermission encodes
the gap worth knowing about
here's the honest version of where things stand
the full zkPermissions rollup — the multichain version that makes these permissions work cost-efficiently across different networks — is listed as upcoming, not live
what exists today is a working implementation using session keys and ERC-4337 smart account standards. the zkPermissions work. but the dedicated rollup that makes them cheap enough to use for high-frequency automation across multiple chains is still on the roadmap
Newton's docs say this explicitly: "launching a zkPermissions rollup that enables cost-efficient, multichain-compatible zero-knowledge permissions" is a forthcoming milestone
so the technical capability is real. the production-grade version that makes it economically viable at scale is what the rollup enables
why the OAuth analogy matters beyond the technical explanation
the reason this analogy stuck with me isn't just that it's a good explanation. it's what it implies about who Newton is actually building for
OAuth didn't become ubiquitous because developers chose it as the most elegant solution. it became ubiquitous because users demanded it — because "sign in with Google" was obviously safer than handing every app a password
if zkPermissions becomes the standard way of delegating to onchain agents, it won't be because the ZK cryptography is impressive. it'll be because users eventually realize that giving an agent a scoped permission is obviously safer than giving it a private key
the adoption path for zkPermissions probably looks a lot like the adoption path for OAuth. slow, then sudden, driven by a security incident that makes the alternative feel obviously wrong
Newton is building the infrastructure for that moment. whether the moment comes before or after the runway runs out is the question nobody can answer from a whitepaper 🙏
$NEWT #Newt @NewtonProtocol

i have a habit that's probably annoying to anyone watching me research i don't stop at the announcement. i go looking for what the announcement actually means technically and whether it holds up
when i saw Newton's github had a reference implementation for ERC-8004, i assumed this was Newton's own standard proposal. teams do this all the time — file an EIP, call it infrastructure, build the narrative
so i went and read the actual proposal. and it changed how i think about this 👀
this is the first thing worth knowing
ERC-8004 was proposed on August 13, 2025 by Marco De Rossi from MetaMask, Davide Crapis from the Ethereum Foundation, Jordan Ellis from Google, and Erik Reppel from Coinbase
that's not a Newton proposal. that's a cross-industry standard being developed by people from some of the most credible institutions in both crypto and traditional tech. the Ethereum Foundation's decentralized AI team has placed it in the 2026 roadmap. Base is confirmed as the next L2 deployment. by Q2 2026, reference implementations were live on Base Sepolia, Linea Sepolia, and Hedera Testnet
Newton didn't propose this standard. they built a reference implementation for it. that distinction matters a lot 🧐
what ERC-8004 actually does
the standard is trying to solve one specific problem: how do autonomous AI agents discover and interact with each other across organizational boundaries without a centralized gatekeeper deciding who's trustworthy
right now if an AI agent from one company wants to interact with an agent from another company — to trade, to delegate, to settle a task — there's no neutral standard for how that trust gets established. each platform builds its own solution. the result is a fragmented agent economy that can't scale
ERC-8004 proposes three trust models for agent verification:
reputation — onchain audit trail of how agents have performed historically
validation — crypto-economic staking or verification by third parties
TEE attestation — hardware-level proof that the agent ran correctly inside a trusted execution environment
and here's the critical line buried in the EIP itself: "while this ERC cryptographically ensures the registration file corresponds to the onchain agent, it cannot cryptographically guarantee that advertised capabilities are functional and non-malicious"
the standard can give an agent an identity. it cannot guarantee that agent behaves correctly. that gap is explicitly acknowledged by the authors 🙏
where Newton sits in this picture
Newton's reference implementation for ERC-8004 is specifically built around the third trust model — TEE attestation
that's not a coincidence. Newton's entire architecture is TEE-based. the policy checks run in hardware-isolated enclaves. the attestations are cryptographically signed. the results are verifiable onchain
the reputation and validation models in ERC-8004 tell you how an agent has behaved in the past and whether someone staked on it being legitimate. the TEE attestation model tells you the agent ran correctly right now, in real time, in hardware you can't tamper with
those are different categories of trust. the first two are probabilistic — past behavior and economic incentives. the third is cryptographic — hardware proof of correct execution
Newton is building the strongest trust model in the standard 👀
the part that reframes the whole thing
here's what i keep coming back to
ERC-8004 becoming an Ethereum standard means every protocol building AI agents will eventually implement some version of this trust layer. reputation, validation, TEE attestation — pick your level of trust depending on the stakes involved
for low stakes agents — content generators, scheduling tools, research bots — reputation and validation are probably enough
for agents moving real money, executing financial decisions, operating within compliance requirements — the TEE attestation model is the only one that actually holds up
and Newton's reference implementation is the only live TEE attestation implementation built specifically for ERC-8004 compliant agents
if the financial AI agent economy scales the way people think it will, the demand for the highest trust model in ERC-8004 is the demand for what Newton specifically built
ERC-8004 is still a draft standard. standards get adopted, modified, or abandoned. the fact that MetaMask, Ethereum Foundation, Google, and Coinbase are co-authoring it is the strongest possible signal it's serious — but serious proposals still fail sometimes
Newton building a reference implementation early is the right move regardless of outcome. if ERC-8004 gets adopted widely, Newton is already the infrastructure for its most rigorous trust model. if it gets modified, Newton's architecture adapts because the TEE attestation approach is sound independent of the specific standard
what i didn't expect when i started reading: this isn't Newton trying to own a standard. it's Newton positioning as the best possible implementation of someone else's standard, built by people from Ethereum Foundation, MetaMask, Coinbase, and Google
that's actually a stronger position than proposing it yourself 😅
$NEWT #Newt @NewtonProtocol

i have a habit when i research infrastructure protocols — i don't stop at what they claim to do. i try to find one specific cryptographic or architectural decision that tells me whether the people building it actually know what they're doing at a deep level
not the partnership list. not the roadmap. the specific technical choice that separates teams who understand the problem from teams who read about it
with Newton i found it buried in the privacy architecture documentation
Newton uses BLS signatures on the BN254 curve for operator attestations
that's a very specific choice and it's the right one. here's why it matters 👀
what BLS signatures actually are
most cryptographic signatures work like this: you get one signature per signer, and verifying multiple signatures requires verifying each one individually. that gets expensive fast when you have a network of operators all checking the same transaction
BLS signatures — Boneh-Lynn-Shacham — have a property that almost no other signature scheme has: aggregation. multiple operators can each sign the same message, and all those individual signatures can be mathematically combined into one single compact signature that proves all of them signed
one verification operation confirms the entire network agreed. not one per operator. one total
Ethereum's beacon chain uses BLS signatures for exactly this reason — hundreds of thousands of validators attest to blocks, and BLS aggregation is what makes verifying all those attestations computationally feasible onchain
Newton made the same choice for the same reason 🧐
the BN254 curve specifically
the curve matters as much as the signature scheme
BN254 is the pairing-friendly elliptic curve that EIP-197 added as a precompile to Ethereum in 2017. what that means practically: BLS signature verification on BN254 is dramatically cheaper onchain than it would be on other curves, because Ethereum has hardware-level support for the mathematical operations BN254 requires
Newton's operator attestations use BN254 specifically. which means every time Newton produces a policy attestation onchain, the verification cost is as low as it can possibly be on Ethereum
that's not an accident. teams that understand how this works choose BN254. teams that don't end up with expensive verification costs that limit how often the protocol can realistically run 🙏
how it works in Newton specifically
when a transaction hits Newton's enforcement layer, multiple operators each independently evaluate it against the policy. each operator produces their own BLS signature on the result
once enough operators agree — a supermajority of the operator network — their individual signatures get aggregated into one compact joint proof. that single aggregated signature is what gets submitted onchain as the attestation
from Newton's own docs: "once enough operators agree the policy is satisfied, their individual approvals are combined into one compact proof: a joint cryptographic signature that means 'a supermajority of the network checked this and reached the same answer'"
one proof. one verification. regardless of how many operators participated 👀
why this specific choice signals something
the practical consequence of using BLS on BN254 is that Newton's attestations are cheap to verify, compact enough to fit efficiently in transactions, and mathematically proven to aggregate correctly
but the signal i keep coming back to is what choosing BN254 specifically tells you about who built this
EIP-197 landed in 2017. the teams that deeply understood Ethereum's cryptographic precompiles and built around them are a small group. Magic Labs being in that group — deliberately choosing BN254 because of EIP-197 — is the kind of detail that only shows up when the people building it come from deep infrastructure background rather than building on top of what's already familiar
Rego for the policy layer. BLS on BN254 for the attestation layer
two choices buried in documentation that most people covering Newton have never read. both the right choices for the same reason — they're what engineers who understand the problem at a deep level would choose, not what a team trying to ship quickly would reach for
the honest observation
none of this matters if the protocol doesn't get used. a perfectly designed cryptographic attestation system that nobody plugs into is still just architecture
but when i'm trying to figure out whether a team actually understands what they're building, i look for decisions like this. technical choices that required knowing something most people don't know, made before anyone was watching
Newton has two of them. that's more than most 😅
$NEWT #Newt @NewtonProtocol

there's a line in Newton's VaultKit announcement that stopped me mid read
not the tech stuff. not the partner list. one specific sentence about what institutions actually need
"the largest asset managers exploring tokenization don't have a discretion problem. they have a provable-control problem. they can already write the policy. what they've been missing is a way to enforce it onchain, verifiably, without handing their compliance logic to the public"
that's an unusually precise claim. most projects say "we're building for institutions." Newton said something more specific: institutions already know how to write compliance rules. the missing piece isn't the policy, it's the enforcement layer that can prove the policy ran without exposing what the policy contains
i wanted to know if the product actually delivers on that specific claim. so i went and looked 🧐
what VaultKit actually does right now
VaultKit is Newton's SDK for vault integrations. it puts a policy check on every curator action before it can touch the vault — reallocate, set a cap, enable a market, change a fee — all checked against a policy before execution
the privacy piece is real. Newton uses ZK proofs so the policy itself stays private while the enforcement record is public. an institution can enforce its compliance logic onchain without publishing its rulebook. that's genuinely the capability they described
the oracle integration is live. Chainalysis for sanctions screening. RedStone for price feeds — RedStone's price feeds now serve as the data backbone for risk-related conditions within Newton's policy engine, with the provider reporting no mispricing events to date across over 100 blockchain networks. Credora for credit risk. Vaults.fyi for vault health ratings. Webacy for wallet reputation
policy packs are open source on github. the SDK is on npm. the infrastructure for the claim they made is actually there
the specific gap i found
here's where it gets interesting
VaultKit currently has specific integration support for one vault platform: Morpho. the docs say explicitly "starting with Morpho and generic call support for other protocols" and that "reference implementations for additional popular vault platforms are forthcoming"
Morpho is a serious protocol. but the institutional vault landscape is bigger than Morpho. Gauntlet's USDT vaults absorbed $775M in supply in a single day in October 2025 — that's the scale of capital Newton is ultimately trying to serve. Euler, Gauntlet, and the other major vault platforms managing billions don't have specific Newton integrations yet
so the claim Newton made — that institutions have a provable-control problem and VaultKit is the answer — is technically correct
but the answer currently fits one vault platform officially, with generic support and forthcoming implementations for the rest
the honest version of what that means
i don't think this is a critical flaw. every infrastructure product launches with a focused integration and expands from there. Morpho is a reasonable starting point — it's one of the most composable vault protocols in DeFi and an integration there proves the architecture works
what it means practically is that an institution running capital through Gauntlet or Euler vaults can't plug Newton in cleanly today. they get generic call support, which requires more custom engineering work than a reference implementation
the provable-control problem Newton identified is real. the solution they built is real. the gap is between "we built the solution" and "the solution is ready to plug into wherever your capital actually sits right now" 🙏
the question worth watching
Newton's blog post says reference implementations for additional vault platforms are forthcoming. the timeline for those integrations is the actual adoption story
because the thesis is right. institutions do have a provable-control problem and not a policy-writing problem. and ZK-enforced onchain compliance that keeps the rulebook private is exactly what they've been missing
but infrastructure adoption in institutional finance moves through specific integrations, not generic support. every additional vault platform that gets a reference implementation is a door that opens to a different set of institutional capital
i'll be watching which platforms come next and how fast. that sequencing probably tells you more about Newton's institutional adoption trajectory than any narrative about what the tech can theoretically do 😅
$NEWT #Newt @NewtonProtocol