TM Phúc

A group of five people co-own a safe. Each holds a fragment of the key. To open it, at least three of them must be in the same room, exchange their fragments, and turn the lock together. No single person can open it alone. The room has to be secure, nobody outside should see which fragments are being assembled. They open the safe, take out the document inside, read it, and sign a statement confirming what they found. Then the safe closes. The fragments go back into each person's pocket.
I started thinking about this while reading through Newton's privacy layer, specifically the threshold decryption mechanism and how operators coordinate internally. The mapping is surprisingly direct.
When a user encrypts sensitive data, PII, credentials, compliance records, they do it locally using HPKE with X25519 and ChaCha20-Poly1305. What comes out is a SecureEnvelope. That envelope gets uploaded to the Gateway, which returns a data_ref_id, essentially a content hash. Only that ID touches the chain. The raw data never appears on any public ledger.
Now, when a policy evaluation needs that data, operators have to open the envelope. But they don't have the full decryption key. Each operator holds only a share of the HPKE private key, generated beforehand through a FROST DKG ceremony, a distributed key generation protocol that produces a shared public key while ensuring no single party ever holds the complete private key. The ceremony runs only when the operator set changes, not per task. That limits the attack surface.
When a task requiring encrypted data arrives, the operators coordinate to decrypt it. They exchange partial decryption shares over NATS, an encrypted publish-subscribe messaging system that operates independently of the Gateway. Each operator computes its share from its DKG fragment, sends it to the others through NATS channels, and once enough t-of-n shares have been collected, each operator reconstructs the plaintext locally. The data only exists in readable form for a brief moment, just long enough to evaluate the Rego policy against it. Then the operators produce their BLS signatures, which get aggregated into a single attestation. The smart contract sees allow or deny. Nothing more.
What I find interesting about this architecture is that the decryption happens inside a temporary, isolated room. The plaintext is never stored. It's never broadcast outside the operator set. The chain only ever sees hashes and commitments. Operators are disincentivized from leaking anything by EigenLayer slashing, which punishes after the fact but makes leaking expensive.
I started comparing this to Anoma's approach, and the contrast is sharp. Anoma uses validation predicates, small programs written in a language like Juvix that run directly in the chain's execution layer. Each predicate is an independent condition that a transaction must satisfy. There are no off-chain operators, no encrypted rooms, no key fragments. The validation happens entirely on-chain, transparently. Anyone can audit the predicates and verify the results. But the data those predicates need, identity proofs, compliance records, whatever, has to be brought on-chain or at least referenced on-chain. That transparency has a cost. Sensitive data risks exposure.
Newton's model sacrifices some transparency in the evaluation process to protect the data. The plaintext is decrypted off-chain, inside that NATS room. Outside observers can't see what the operators saw. They can only verify the BLS aggregate signature, which proves that a quorum of operators agreed on the result. For a financial institution that needs to prove compliance without broadcasting customer data, this makes sense. The auditor gets cryptographic proof that a policy was evaluated. They don't get the raw KYC documents. For Anoma's model, the transparency is the point. The entire evaluation is on-chain, auditable by anyone. But that also means sensitive data either stays on-chain or is pushed to a different layer.
I keep turning over the availability question for Newton's model. NATS has to be running. The operators have to be online and able to exchange shares. If NATS goes down or experiences a network partition, the threshold decryption stalls. Tasks that depend on encrypted data fail, not because the policy rejected them, but because the math couldn't be performed. The DKG ceremony itself is another critical moment. If the ceremony is compromised, an attacker could reconstruct the full HPKE private key. The docs limit this by only running ceremonies during operator set changes, but that window, however rare, is the moment where the entire privacy guarantee rests.
I don't have a clean comparison. Anoma's predicates are transparent and auditable but expose data. Newton's threshold decryption protects data but introduces dependencies on NATS and the DKG ceremony. Two different directions, two different sets of trade-offs. I'm still trying to figure out which model handles real-world compliance workloads better, especially as the number of operators and the volume of sensitive data both grow. The meeting room has to stay secure, and the participants have to show up. That's the part I keep thinking about.
@NewtonProtocol #Newt $NEWT

I used to work at a company with a satellite office in another city. Every morning, someone from HR would email the local security desk an updated list of active employees. The guard printed it out, checked IDs against it, and anyone not on the list didn't get in. If HR forgot to send the email, or if the list had a typo, people got stuck at the door. The alternative, which we briefly considered, was to let everyone in and just fire anyone who let in a former employee without authorization after the fact. Audit the logs, not the door. We never implemented that, because the cost of a single wrong entry was too high. But I remember thinking it was two fundamentally different ways to handle the same problem. One checks before access. The other checks after.
I started thinking about this again when looking at Newton Protocol's cross-chain security model. Newton's AVS operators sit on Ethereum. But PolicyClient contracts that enforce attestations can be deployed on other chains, like Base. Those destination chains need to verify that a BLS attestation is legitimate without having the full operator set on-chain. Newton's solution is a Table Syncer, a piece of infrastructure that proactively pushes operator state from the source chain to each destination chain. It reads BLS public keys, stake weights, and a Merkle tree of all active operators from Ethereum. It packages that into a BN254OperatorSetInfo struct containing the Merkle root, the number of operators, the aggregate public key, and total weights. Then it calls confirmGlobalTableRoot and updateOperatorTable on the destination chain's ECDSAOperatorTableUpdater. The BN254CertificateVerifier contract on the destination chain uses this cached snapshot to validate BLS certificates without ever querying Ethereum directly.
What catches my attention is a detail buried in the docs. These updates have to be atomic. If the Table Syncer sends two sequential transactions instead of batching everything into one, each transaction overwrites the previous state partially. The Merkle root updates but the operator count doesn't, or vice versa. That creates an intermediate state where non-signer Merkle proofs fail validation. The error message is InvalidOperatorIndex, and the destination chain verifier breaks until the state is consistent again. It's the kind of sharp edge that only shows up during an incident, maybe after a gas spike forces the syncer to split a batch, or when someone deploys a new version and forgets the batching requirement.
Optimism Bedrock takes the opposite approach. Instead of proactively syncing validator state to the L2, the sequencer posts transaction batches and state roots to Ethereum. Those state roots are assumed valid by default. There's no guard at the door checking IDs. Instead, there's a 7-day challenge window. Any honest watcher can submit a fraud proof showing the sequencer computed the wrong state root. If the proof is valid, the incorrect state root is discarded, the sequencer gets slashed, and the chain rolls back. The system trusts that at least one honest actor is watching and has enough capital to challenge within the window.
The trade-off is clear but worth laying out side by side. Newton's model verifies before executing. You check the attestation against a cached operator set right now. If the Table Syncer is down, transactions on destination chains stall. You can't verify new attestations because the BN254CertificateVerifier doesn't have fresh state. The security is at the point of execution, but the liveness depends on a centralized piece of infrastructure. Optimism's model executes first and verifies later. Transactions on L2 never stall due to missing operator state because there's no cached state to miss. But withdrawals back to Ethereum are delayed by the challenge window. The liveness is better, but the finality is slower.
I find myself wondering which dependency is harder to manage. Running a reliable syncing service is an engineering problem. You need monitoring, failover, gas management, and careful testing of the batching logic. Ensuring there's always at least one honest watcher with enough capital to challenge a fraudulent state root is an economic one. Both can fail. The Table Syncer can go down. The watcher can lose interest or run out of funds. Different failure modes, different costs.
What I haven't seen yet is who controls the Table Syncer. If it's a single key, that key can push a malicious operator set to the destination chain. The verifier would trust it, and attestations would be validated against fake keys. The slashing happens back on Ethereum, but the damage on the destination chain is already done. If it's a multisig or a DAO, the trust is distributed but the operational complexity increases. The docs don't specify this, and I think it's an important detail for anyone deploying a PolicyClient on a destination chain. The security of the whole cross-chain flow inherits the governance of the Table Syncer.
I keep coming back to the memory of that satellite office. We needed the email to arrive every morning. If the internet was down, people waited outside. The alternative of auditing after the fact felt reckless for a company that dealt with sensitive data. Newton's model feels like the right instinct for a policy engine where you need to block a non-compliant transaction now, not in seven days. But the email still has to arrive. And someone has to make sure it's sent correctly, every single morning. That's the part I'm still thinking about.
@NewtonProtocol #Newt $NEWT

A real estate appraisal committee. Three independent valuers assess the same property. Each pulls their own comparable sales data, checks market conditions, runs their numbers. Then they sit down together. If one valuer says the property is worth half a million and another says eight hundred thousand, someone's data is off. They don't average the two and move on. They identify the outlier, check whose data was wrong, and if the discrepancy exceeds the acceptable range, they halt the process entirely. Only when all three valuations fall within a tight band do they sign the final report. That report then goes to the bank's headquarters, where a clerk checks only one thing: whether all three signatures are present and valid. The clerk doesn't re-run the valuation. They don't know the property. They just verify the signatures against the registered list of authorized valuers.
I started thinking about this when I was trying to understand Newton's Prepare-Commit consensus and how it connects to their multichain architecture. The two mechanisms look separate at first glance, one is about aligning oracle data, the other is about verifying proofs across chains. But they share a deeper pattern that took me a while to notice.
Let me start with the Prepare-Commit flow. When a task hits the Gateway, operators don't just fetch the policy and sign. They go through two distinct phases. In Prepare, each operator independently calls whatever external data sources the policy requires: price feeds, KYC oracles, sanctions lists. They return their raw, unsigned responses. The Gateway collects all of these and computes a median for each numeric field. Then it checks tolerance. If any operator's value deviates more than 10% from the median, the consensus fails right there with ToleranceExceeded. The outlier isn't silently excluded. The whole thing stops.
If all values are within tolerance, the Gateway normalizes everything to the median and broadcasts the canonical dataset for the Commit phase. Now every operator evaluates the policy against identical inputs. They each produce a BLS signature on the same message. Those signatures get aggregated into a single proof.
I find this two-phase design worth paying attention to because it solves a problem that's easy to overlook. Operators calling external APIs will naturally get slightly different answers. A price ticker might return 100.0 for one operator and 100.3 for another, simply because milliseconds passed between their calls. In most oracle designs, this variance is either ignored or handled by trusting a single data source. Newton forces consensus on the data itself before anyone signs anything. The median becomes the truth, but only if the spread is narrow enough. If the spread is too wide, the system prefers to fail rather than sign a questionable result.
The tradeoff is latency. Two full rounds of communication before the attestation exists. And the Gateway has a privileged position during that window. It computes the median. It decides what the canonical values are. A compromised Gateway could theoretically feed a manipulated median to the operators, and they would sign it faithfully because from their perspective, the data looks canonical. The safeguards are narrow: operators can choose not to sign if something seems off, and if enough abstain, quorum fails. But that's a reactive defense, not a cryptographic one. I don't know how well it holds up under a sophisticated attack.
Now, where the multichain part gets interesting is how this consensus result moves across chains. Newton's operators live on a source chain, Ethereum mainnet or Sepolia. But PolicyClient contracts can be deployed on destination chains like Base or Arbitrum. The attestation produced on the source chain needs to be verified on a completely different chain. They do this with BN254 certificates. The BLS aggregate signature is encoded into a certificate that a lightweight verifier contract on the destination chain can check. The destination chain doesn't re-run the policy. It doesn't query the operators. It just verifies the math against a cached snapshot of the operator set.
This is where the appraisal committee analogy comes back. The bank headquarters, the destination chain, doesn't redo the valuation. It checks the signatures. The operator state has to be synced from the source chain to the destination chain via a table syncer service that periodically pushes BLS keys, stake weights, and Merkle roots. If that sync lags, the verifier is checking against stale data. If the sync is done in multiple transactions instead of one atomic batch, intermediate states can break Merkle proofs and cause verification failures. The docs explicitly warn about this. It's a sharp edge that someone has to manage operationally.
The challenge flow is split too. If an attestation on a destination chain is disputed, the attestation gets invalidated locally. But the actual slashing, the economic penalty, happens back on the source chain. That's where the operator stake lives. The destination chain can't slash. It can only refuse to execute. So there's a gap between invalidation and punishment. During that gap, a malicious operator might try to exit. The security relies on EigenLayer's withdrawal delay being long enough to close that window.
I keep coming back to how these two mechanisms, Prepare-Commit and cross-chain verification, share the same instinct. Both are about making sure that what gets signed and verified is consistent, even when the data sources and the enforcement points are distributed across different systems. The Prepare phase aligns data across operators. The BN254 certificate aligns verification across chains. Both introduce dependencies: the Gateway in Prepare, the table syncer in multichain. Both have failure modes that are manageable under normal conditions but could cascade under stress.
I'm still trying to figure out if these dependencies are acceptable engineering tradeoffs or if they concentrate trust in ways that undermine the decentralization of the rest of the system. The architecture is clever. But clever architectures have a way of failing at the joints between components. I'm not sure yet whether Newton's joints are reinforced enough. Still looking at them.
@NewtonProtocol #Newt $NEWT

A speed limit sign tells you to slow down. A speed bump forces you to. One is a request. The other is physics. I keep thinking about this distinction when I look at how we try to control autonomous AI agents today.
Most AI agent frameworks rely on software limits. You set an API budget in a dashboard. You write a system prompt that says "never transfer more than $100." You configure rate limits on a server. These are speed limit signs. They work until the agent finds a loophole, or a prompt injection tells it to ignore previous instructions, or a bug in the rate limiter lets a transaction slip through. The constraint lives inside the same system as the agent. If the sandbox breaks, the limits break with it.
Newton takes a different approach. Instead of embedding limits inside the agent's code, you write them as a Rego policy. That policy is stored on IPFS with a content-addressed CID. The agent doesn't check its own limits. It submits an intent to a decentralized network of operators. Those operators fetch the policy, evaluate the intent against it, and collectively produce a BLS aggregate signature. The smart contract that controls the funds verifies that signature on-chain. If the policy says no, the transaction doesn't execute. The agent can't negotiate with the speed bump.
I can see the appeal. The enforcement is external. The entity that wants to act isn't the same entity that checks the rules. In the Web2 model, if you want to raise the limits, you log into a dashboard and click a button. With Newton, changing the policy means updating the CID reference on-chain, which is a transparent governance action. The old policy still exists, the new one is verifiable. An auditor could trace exactly what changed and when.
But I'm not sure this is the whole story. There are real questions I keep bumping into. What happens when the operators collude? EigenLayer slashing is supposed to deter that, but slashing is reactive. The damage happens first. And the policy itself is only as good as the data it consumes. If the WASM oracle feeding the price is wrong, the operators might faithfully approve a transaction that shouldn't have gone through. They followed the rules. The trust didn't disappear, it just shifted from the agent's code to the oracle's data feed. Is that better? I honestly don't know.
Then there's the speed question. An API limit check takes milliseconds. Newton's flow requires a round trip through a gateway, operator evaluation, BLS aggregation, and on-chain verification. That's not fast. For a high-frequency trading bot, the latency alone might make it unusable. For a DAO treasury agent moving funds once a week, maybe it's acceptable. The use case matters a lot here.
I also wonder about the operator network itself. If quorum fails or the gateway goes down, the agent simply can't move. A Web2 API limit, for all its flaws, doesn't have that dependency. It's a single point of failure, but it works as long as the server is up. Newton adds moving parts. Each one is a potential failure mode.
The core idea makes intuitive sense: don't let the agent police itself. Externalize the enforcement. Make it cryptographically verifiable. But whether the added complexity and latency are worth it probably depends on what's at stake. A chatbot with a $10 monthly limit doesn't need onchain policy enforcement. A treasury agent controlling millions might. I'm still trying to figure out where the threshold sits. Not a clean answer. But I'm not sure there is one.
@NewtonProtocol #Newt $NEWT