Just been reflecting on something from my family’s small trading business. We need any two of three signatures (dad and my two uncles) for amounts above a certain limit.
One time the bank cashier held a payment the whole afternoon because one uncle’s signature looked a tiny bit different from the specimen card. They basically did two checks at once: does this ink match the person, and is this person even allowed to sign?
I thought Newton’s policy stuff would only handle the “allowed” part, leaving the actual signature verification to crypto layers outside it. But reading deeper, it’s all in one place.
Their policy can recover the real signer straight from the raw signature using ecdsa.recover inside Rego.
So in the multisig example, it pulls the Ethereum addresses, checks who’s authorized, and approves only when two genuine ones match. Super clean.
The delegation example felt even more real Alice gives Bob authority, Bob signs the transaction. The policy verifies both signatures in one go: the actual intent and the delegation document, checks it hasn’t expired, etc. Like a proper power of attorney but fully in code.
What I like is it stays deterministic, so the zero-knowledge proofs can still work with it later.
One thing I’m curious about though — when you need to change a signatory (say an uncle steps back and someone else steps in), is it just updating the external data list or do you have to republish the whole policy? Anyone here dealt with updating authorized signatories on a business account? How much of a headache was it?
Crypto loves going super fast and then acting surprised when things break. Newton seems to be trying to put sensible rules in front before the money moves, instead of cleaning up after. Not the loudest idea in the space, but one that actually feels useful.
$NEWT #Newt @NewtonProtocol
One time the bank cashier held a payment the whole afternoon because one uncle’s signature looked a tiny bit different from the specimen card. They basically did two checks at once: does this ink match the person, and is this person even allowed to sign?
I thought Newton’s policy stuff would only handle the “allowed” part, leaving the actual signature verification to crypto layers outside it. But reading deeper, it’s all in one place.
Their policy can recover the real signer straight from the raw signature using ecdsa.recover inside Rego.
So in the multisig example, it pulls the Ethereum addresses, checks who’s authorized, and approves only when two genuine ones match. Super clean.
The delegation example felt even more real Alice gives Bob authority, Bob signs the transaction. The policy verifies both signatures in one go: the actual intent and the delegation document, checks it hasn’t expired, etc. Like a proper power of attorney but fully in code.
What I like is it stays deterministic, so the zero-knowledge proofs can still work with it later.
One thing I’m curious about though — when you need to change a signatory (say an uncle steps back and someone else steps in), is it just updating the external data list or do you have to republish the whole policy? Anyone here dealt with updating authorized signatories on a business account? How much of a headache was it?
Crypto loves going super fast and then acting surprised when things break. Newton seems to be trying to put sensible rules in front before the money moves, instead of cleaning up after. Not the loudest idea in the space, but one that actually feels useful.
$NEWT #Newt @NewtonProtocol