Sattar Chaqer

I keep noticing how many investment mandates are still written for a world where transactions move slowly and people stay in the loop.
A fund’s concentration limit sits in an investment memo. A DAO treasury’s approved asset list lives in a governance post. A liquidity requirement gets written into an operating policy and shared with the team managing the capital. Everyone involved may understand the rule. It may even be formally approved and carefully documented.
But none of that means the transaction system itself can actually read it.
That feels like a bigger problem than it first appears.
An investment mandate is supposed to shape how capital gets deployed. It might define how much exposure can go into one strategy which venues are approved what kinds of assets are allowed how much liquidity has to be maintained or what kind of risk profile the portfolio should stay inside. In theory those rules are part of how the capital is governed.
In practice though many mandates are still written in a format that assumes a person will interpret them and apply them at the right moment.
That made more sense in slower financial environments.
A portfolio manager reads the mandate and tries to stay inside it. A compliance team reviews trades later and checks whether anything drifted outside the agreed boundaries. An allocator or auditor verifies the process after the fact. The model assumes that the mandate exists as a human readable instruction and that the people around the capital will carry it into execution correctly.
The problem is that onchain finance doesn’t really operate at the speed that model expects.
A treasury can move capital across multiple venues in a day. A vault can rebalance continuously. A strategy can route assets through several protocols without ever passing through the kind of slow review cycle traditional mandates quietly assume. As execution becomes more automated the gap between the mandate as written and the transaction as executed gets much harder to ignore.
The issue is not just that someone might break the rule.
It is that the rule often exists in the wrong format for the system it is trying to govern.
A written concentration limit is useful to a portfolio manager.
It is not useful to a smart contract.
A list of approved venues makes sense in an allocator memo.
It does not automatically mean the transaction system knows how to reject a move into an unapproved market.
A liquidity threshold can be written clearly in a treasury policy but unless the execution path can actually evaluate that threshold before capital moves the mandate still depends on a person remembering to apply it.
That is where I think Newton becomes interesting in a way that goes beyond generic compliance language.
Newton’s model suggests that the problem is not only whether a rule exists. The problem is whether the rule exists in a form the transaction system can actually use.
That is a different question.
A human readable mandate is still a document.
A machine enforceable mandate is closer to executable policy.
The first tells people what should happen.
The second gives the transaction system a way to check whether the proposed action fits the mandate before it goes through.
I think that distinction matters because a lot of investment governance still assumes that writing the rule and enforcing the rule are basically the same thing. They are not.
Writing no more than 20% in a single venue is not the same as having a system that can stop the 21st percent from being allocated there.
Writing only approved assets may be held is not the same as having a transaction path that can reject an allocation into something outside the approved set.
Writing maintain minimum liquidity buffers is not the same as having execution logic that can actually test whether the move would break that requirement.
In older systems that gap was often covered by process.
In onchain systems process starts to look thinner because execution can happen much faster than human review.
That is why I think the real issue is not simply that mandates need to be enforced more carefully. It is that mandates increasingly need to be expressed in a form that can survive machine speed execution.
Newton’s authorization layer points in that direction.
Instead of treating the mandate as something a person reads and then tries to honor manually the mandate can be translated into policy that gets evaluated before the transaction settles. A concentration limit an approved counterparty list a venue restriction or a liquidity floor can become part of the transaction decision itself rather than remaining a static document sitting beside it.
That changes the role of the mandate.
It stops being just an instruction for the operator.
It becomes something much closer to an execution condition.
I think that matters because investment mandates are really about controlling discretion.
They exist because allocators treasury committees funds and governance bodies do not want every decision left entirely to whoever controls the wallet or manages the strategy. They want to define boundaries in advance. The problem is that those boundaries lose force when they are written in a format that only works if a person remembers to apply them correctly every time.
A machine readable policy changes that dynamic.
It does not decide what the mandate should be. Humans still choose the concentration limit the venue list the liquidity requirement or the asset restrictions. But once those choices are made the system no longer has to rely entirely on memory diligence and downstream review to keep execution inside the agreed boundaries.
That is a much stronger model for onchain capital.
Not because it removes humans from the process but because it stops assuming that human readable text is enough to govern machine speed transactions.
To me, that is the deeper point behind Newton’s mandate angle.
The protocol is not just asking whether investment rules exist.
It is asking whether those rules are written in a form the transaction system can actually understand.
Because if the mandate can only be read by humans then the capital is still being governed by a document sitting outside the execution path.
And as more treasury systems vaults and tokenized portfolios move onchain that starts to look like a fragile place for the rules to live.
Eventually the mandate has to become readable by the same system that moves the capital.
Otherwise it remains what many mandates already are today.
clear on paper but one step removed from the transaction it was supposed to govern.
@NewtonProtocol $NEWT #Newt $LAB $TAC

I keep coming back to a distinction that feels easy to miss in crypto AI conversations.
Giving an AI agent a wallet is not the same as deciding what that agent is actually allowed to do with it.
One is access.
The other is a boundary.
Right now a lot of agentic crypto setups seem to have the first part but not the second. A wallet gets funded an agent gets the ability to sign and the rest is mostly trust. Trust that the model will behave as intended. Trust that the prompts are safe. Trust that the logic won’t drift. Trust that a bug exploit or bad external input won’t push the system into an action nobody meant to authorize.
That model starts to look fragile the moment agents stop acting like assistants and start acting like operators.
An agent that only summarizes information or drafts trade ideas is one thing. An agent that can execute a swap move treasury funds rebalance a position or interact with a protocol on its own is something else entirely. Once the agent can initiate real onchain actions, the question is no longer just whether it has a wallet.
The real question becomes.
what is that wallet allowed to do before value actually moves?
That distinction matters because a wallet does not understand intent.
A wallet can verify signatures. It can hold funds. It can sign transactions if the right key is available. But it does not know whether a proposed trade fits a treasury mandate whether a transfer exceeds a risk limit, or whether the agent is interacting with a contract it was never supposed to touch in the first place.
From the wallet’s perspective a transaction is usually just something to sign if the key is available. It does not know the difference between an agent acting within policy and an agent doing something it should never have been allowed to do.
That is where I think the current AI agent conversation in crypto still feels incomplete.
A lot of attention goes toward giving agents more capability more tools more execution rights more autonomy. But capability without boundaries creates a very strange security model. The system becomes increasingly automated while the control layer often remains very thin. If the agent has broad wallet permissions then a prompt injection a strategy error a bad integration or a simple bug can still produce a perfectly valid onchain transaction.
Valid is the important word there.
Because the blockchain may see nothing wrong with it at all.
The signature can be correct.
The wallet can have the funds.
The contract call can be executable.
The transaction can be technically valid.
And yet it may still be a transaction the human behind that agent never wanted to permit.
That is why I think agent infrastructure needs something stronger than wallet access. It needs a way to separate the agent’s ability to propose an action from the system’s decision about whether that action is actually allowed to execute.
This is where Newton starts to make sense to me.
Newton is built as an authorization layer that sits between transaction intent and blockchain settlement. Instead of assuming that any action proposed by the wallet should move directly to execution Newton inserts a policy check before value moves. The transaction is evaluated first and only if it satisfies the defined rules does it continue toward settlement.
For an AI agent, that changes the meaning of wallet access quite a lot.
The wallet can still exist. The agent can still propose actions. But the transaction no longer depends only on whether the agent has the key or whether the transaction is technically valid. It also depends on whether the action fits the rules defined around that agent.
That is a much more useful model.
It means an agent can operate with permission boundaries instead of broad open ended signing power.
Those boundaries could look like.
only interacting with approved protocols
only sending funds to approved counterparties
daily or hourly spending limits
transaction size thresholds that trigger additional approval
restrictions on specific assets venues or actions
rules that block activity outside a defined strategy scope
What matters is not the specific policy. What matters is where the policy lives.
In a weak agent setup the boundary mostly lives inside the model the prompt or the application logic around it. You hope the agent follows the instructions because that is how it was designed.
In a stronger setup the boundary sits outside the agent and checks the transaction before execution.
That is the shift I find most interesting in Newton.
The agent can still be useful flexible and fast. But the system no longer has to trust the agent alone to define the limits of its own behavior. The authorization layer can act as a separate control plane between agent intent and capital movement.
That changes where trust sits.
In the older model trust is concentrated inside the agent stack itself the model the prompt the orchestration logic and the wallet permissions attached to it.
In Newton’s model trust moves toward a policy layer that is external to the agent. The model can still generate ideas and propose transactions but the decision about whether those actions satisfy the allowed boundaries is checked somewhere else before execution.
I think that separation matters because it makes the system more resilient to the exact thing agentic systems are bad at avoiding unexpected behavior.
An agent does not need to be malicious to create risk. It only needs to be wrong once in a context where the wallet has too much freedom.
That’s why I don’t think the most useful question is can the agent use a wallet?
The better question is what happens when the agent tries to do something outside the boundary it was given?
If the answer is nothing as long as the transaction is valid and the key can sign it then the system still relies too heavily on the agent behaving perfectly.
If the answer is the transaction fails because it didn’t satisfy the authorization policy that is a very different level of control.
Newton doesn’t solve every part of the AI agent problem. It doesn’t decide whether an agent’s strategy is good whether its reasoning is sound or whether its market assumptions make sense.
What it can do is narrower and in some ways more important.
It can help define the space an agent is allowed to act within before the transaction ever reaches settlement.
To me that is the real significance of the model.
The point is not to make the agent smarter.
The point is to stop wallet access from being mistaken for permission.
Because those are not the same thing.
A wallet gives an agent the ability to act.
An authorization layer can decide whether that action should actually be allowed to happen.
And as more agents start handling real capital onchain, that distinction feels less like a nice security improvement and more like a basic piece of financial infrastructure.
@NewtonProtocol $NEWT #Newt $SKYAI $POWER

I keep noticing that onchain vaults have solved one part of capital management much faster than the other.
They have moved the assets onchain.
But the rules governing those assets still often live somewhere else.
A vault can hold capital onchain rebalance across markets and route funds through programmable infrastructure. Yet the instructions shaping those decisions are often still written as governance guidance treasury playbooks allocator mandates or internal operating rules. The vault is onchain but the mandate around it is still partly offchain.
That gap matters because a vault is not only a pool of assets. It is also a system of permissions.
Someone decides which markets can be enabled how much capital can move into a position what fee settings are acceptable and when exposure should be reduced. In most vaults those decisions are concentrated in a curator or manager role. That means the capital may be onchain while the rules around the manager are still mostly a matter of trust.
A curator may be told not to allocate more than a certain percentage to one market.
A treasury operator may be expected to avoid certain counterparties. A fund manager may be working under limits on concentration liquidity or risk.
But if those instructions exist mainly as documents dashboards or internal processes the vault still depends on the human operator following them correctly.
That is not the same as the vault enforcing them.
The more I look at Newton’s vault architecture the more I think this is one of the clearest examples of what the protocol is trying to fix.
Newton’s approach is interesting because it treats vault rules as something that can sit inside the transaction path not just around it. Instead of leaving a curator’s mandate as offchain guidance it moves those rules closer to the action itself so they become part of the authorization process that determines whether the vault action can execute at all.
That changes the model in a very important way.
The old model sounds like this.
The curator promises to follow the rules.
Newton’s model is closer to this.
The vault action only executes if the rules are satisfied.
That is a very different standard.
To see why it helps to think about the kinds of actions vault managers actually perform.
A curator may want to reallocate capital from one market to another. They may want to raise or lower a cap enable a new venue adjust a fee or move assets according to a new strategy decision. On paper all of those actions can be subject to rules.
A vault might have a concentration limit that prevents too much capital from going into one market.
It might require a minimum liquidity threshold before a new venue can be enabled.
It might block interaction with certain counterparties.
It might restrict how much can be moved in a single step.
These are not abstract compliance questions. They are operating rules around capital deployment.
The problem is that most vault systems do not automatically treat those rules as transaction level logic. They treat them as expectations around the manager.
That means the key question is often not does this action satisfy the vault’s mandate?
It is closer to do we trust the manager to follow the mandate?
Newton tries to replace that trust assumption with a policy check.
In Newton’s vault model the curator still uses the tools and workflow they already operate with but the action can be routed through an authorization layer before it touches the vault. That means a reallocation cap change fee adjustment or market enablement can be checked against the relevant policy before execution. If the action is within the defined rules it proceeds. If it is not it does not execute. VaultKit describes this directly it puts a policy check on management actions like reallocate set a cap enable a market or change a fee so the vault action is checked before it reaches the vault itself.
I think that is one of the strongest ways to understand Newton’s role in vault infrastructure.
It is not trying to become the vault.
It is trying to become the layer that decides whether the manager’s action is acceptable before the vault accepts it.
That matters because the vault manager key is usually where a huge amount of trust is concentrated.
Whoever controls that key can often move depositor capital change strategy parameters adjust limits or alter market exposure. In crypto native environments that level of trust was often accepted because the participants understood the model they were entering. But once vaults start handling larger pools of capital tokenized funds treasury assets or institutional allocations trust the curator becomes a much weaker answer.
The capital may be onchain but the governance around it still depends on whether the operator behaves as expected.
Newton’s design pushes against that.
Instead of asking depositors allocators or treasury stakeholders to trust that the manager followed the instructions it tries to make the instructions part of the execution path itself. A rule like never allocate more than 40% to one market or only enable markets above a certain liquidity threshold can be expressed as policy and checked before the action goes through. VaultKit explicitly frames this as turning the curator promises to follow the rules into rules the vault itself enforces before each management action executes.
That is a much more interesting model than ordinary vault governance.
It means the question changes.
Instead of asking whether the curator generally follows the mandate the system asks whether this exact action satisfies the mandate right now.
That difference changes where control actually lives.
In the old model the mandate is mostly a human instruction.
In Newton’s model the mandate becomes much closer to transaction logic.
And that matters because vault rules are often most valuable at the moment an action is about to happen not in a post trade report explaining what should have happened.
If a vault policy says capital should not exceed a concentration threshold the important thing is not whether the rule appears in a governance document. The important thing is whether the rebalance is blocked before it violates that threshold.
If a treasury policy says a manager should not interact with a certain venue the important thing is not whether the policy exists in a committee memo. The important thing is whether the action is stopped before the funds are moved.
To me, that is the real shift.
A vault is not fully governed onchain if the assets live onchain but the rules around those assets still live as offchain instructions.
Newton’s contribution is to narrow that gap.
It takes rules that would normally sit in governance docs treasury guidelines or allocator playbooks and tries to turn them into transaction level logic that can decide whether the vault action executes at all.
That feels like a meaningful step forward for onchain capital management.
Because moving assets onchain was only part of the job.
Eventually the mandate has to move there too.
@NewtonProtocol $NEWT #Newt $EVAA $EDGE

I keep noticing that blockchains are very good at answering one question but much weaker at answering another.
They are very good at deciding whether a transaction is valid.
Is the signature correct?
Does the sender have the funds?
Is the nonce right?
Does the contract call execute under the rules of the chain?
If the answer is yes the blockchain can process it.
That is one of the biggest strengths of onchain systems. They are precise, deterministic and efficient at deciding whether an action can be executed under protocol rules.
But the more I look at Newton’s architecture the more I think there is a second question that matters just as much in financial systems.
Even if a transaction is valid should it actually be allowed to happen?
That is not the same question.
And I think the gap between those two ideas explains a lot about why Newton exists.
A valid transaction is a transaction the blockchain can execute.
An allowed transaction is a transaction that satisfies the policy mandate or authorization logic attached to the capital or application behind it.
Those are related ideas but they are not identical.
A blockchain can tell you whether a transaction is technically acceptable to the network. It does not automatically know whether that same transaction is acceptable to a treasury policy a vault rule set an issuer restriction or an authorization framework designed around a specific use case.
That is where validity stops being enough.
A wallet can sign a transaction correctly.
A contract call can be executable.
The sender can have the assets.
The transaction can satisfy the chain’s rules.
And yet the action might still be something the surrounding financial system would not want to permit.
That is the gap Newton is trying to address.
What makes a transaction valid
Validity is mostly a technical judgment.
The network asks questions like.
Is the transaction formatted correctly?
Is the signature legitimate?
Does the sender control the assets being moved?
Does the contract call execute under the current state?
Does it satisfy the rules of the chain and smart contract?
If the answer is yes the transaction can move forward in blockchain terms.
That is why blockchains are such strong settlement systems. They are very good at evaluating whether an action can be processed according to protocol logic and then finalizing the result.
But validity is still a narrow category.
It tells you whether the chain can execute the action. It does not tell you whether the action should be permitted under a broader set of transaction controls.
What makes a transaction allowed
Allowance is a different kind of judgment.
Here the question is no longer whether the transaction can execute. The question becomes whether the transaction is permitted under the rules governing that capital or that application.
That might include.
a vault mandate limiting which assets can be moved.
a treasury rule blocking transfers above a threshold.
an issuer restriction tied to a specific action.
a strategy rule limiting which contracts or counterparties can be used.
an agent permission boundary defining what an automated system is allowed to do.
None of those questions are automatically answered by ordinary blockchain validity checks.
The blockchain can still say the transaction is valid.
Newton is focused on the separate question of whether it is allowed.
That difference becomes clearer in a treasury or vault setting.
Suppose a treasury wallet is technically capable of sending assets to a certain address. The signature is correct the wallet has the funds, and the transaction would execute normally onchain. In blockchain terms that action is valid.
But what if the treasury policy says that wallet cannot transfer more than a certain amount without approval? Or cannot move capital into a specific strategy? Or cannot interact with contracts outside an approved set?
Now the situation changes.
The transaction may still be valid in blockchain terms but it may not be allowed under the rules governing that treasury.
That is exactly the distinction normal settlement logic does not capture very well on its own.
Settlement logic answers whether the action can happen onchain.
Authorization logic answers whether the action should be permitted under the rules surrounding it.
I think that is one of the cleanest ways to understand Newton.
Newton is not trying to replace the blockchain’s ability to determine validity. It is introducing another decision layer that can evaluate allowance before settlement proceeds.
That means the system no longer depends only on the chain’s answer to the question can this transaction execute?
It can also ask.
Does this transaction satisfy the policy required to make execution acceptable?
That second question is where financial systems start to look very different from simple token transfers.
A basic transfer may only need network validity. But once capital is operating under mandates restrictions treasury controls allocator rules or automated strategies validity alone becomes too thin a standard.
A transaction can be perfectly valid and still violate the rules of the system it belongs to.
That is why I think valid and allowed should be treated as two different system states.
A valid transaction has passed technical checks.
An allowed transaction has passed authorization checks.
A valid transaction may be executable.
An allowed transaction is executable and permitted under the rules attached to it.
That is a stronger requirement.
Without an authorization layer systems are forced to handle allowance through weaker methods. Some rely on application logic around the transaction. Some rely on internal approvals. Some rely on monitoring or offchain restrictions. But the blockchain itself still mostly sees the final signed action and asks whether it is valid enough to execute.
Newton inserts another stage before that final step.
Instead of going directly from transaction intent to settlement the action can first be evaluated under the policy conditions attached to it. That creates room for a transaction to be blocked not because it is invalid in blockchain terms but because it is not authorized under the rules of the system using it.
To me, that is the real difference.
A blockchain can tell you whether a transaction fits the rules of execution.
Newton is trying to tell you whether that same transaction fits the rules of permission.
And as onchain finance becomes more complex that feels like a distinction that matters much more than people first assume.
@NewtonProtocol $NEWT #Newt $VANRY $BLUR

One thing that stands out to me about Newton is that it treats authorization as an actual transaction process not just a general idea that happens somewhere before settlement.
That matters because a lot of onchain systems still compress everything into one step. A user signs a transaction sends it to the blockchain and the network checks whether it is valid under protocol rules. If it is execution happens and settlement records the result.
Newton introduces a different flow.
Instead of sending a transaction directly from intent to settlement it places an authorization layer in between. A proposed action is submitted evaluated against policy agreed on by the authorization network turned into a signed result and then used to determine whether execution should proceed.
The easiest way to understand the flow is this.
Intent → Evaluation → Consensus → Attestation → Enforcement
What I find interesting is that each part has a distinct role. Together they turn authorization into a defined operational sequence rather than a vague promise that checks happened somewhere in the background.
Intent
The flow begins with a proposed action entering Newton before it is executed onchain.
That action could be a transfer a vault rebalance a redemption request or another financial operation. The important point is not the specific transaction. It is the timing. Newton sees the action before settlement.
That changes the shape of the transaction lifecycle.
In a normal blockchain flow the signed transaction is usually the starting point. Once it is submitted the network focuses on execution and finality. Newton inserts a stage before that by treating the action as an intent that can still be evaluated before it reaches settlement.
That creates a place where rules can affect the transaction before value moves.
Evaluation
Once the intent enters Newton the system evaluates it against the relevant policy conditions.
Those conditions can vary depending on the application. They might involve transfer restrictions vault parameters asset limits user linked conditions or other programmable rules attached to the transaction.
The important thing is that Newton treats those rules as live decision logic rather than background process.
The transaction is no longer just an instruction to move value. It becomes something that must satisfy defined conditions before the system allows it to continue.
So the key question at this stage is simple.
Does this proposed action satisfy the rules required for execution?
If the answer is yes the flow continues. If not the transaction should stop there.
Consensus
After evaluation Newton moves into consensus.
This step matters because the authorization result is not left to one private actor making a hidden decision. Instead the network reaches agreement on the outcome of the evaluation.
That changes the role of authorization.
Without consensus the process would still look like an internal approval engine sitting inside a product backend. A team could say it checked the rules but everyone else would still have to trust that claim.
Consensus turns the result into shared infrastructure.
The authorization outcome is no longer just one party’s private judgment. It becomes a network level result produced by the authorization layer itself.
Attestation
Once the network reaches agreement Newton produces an attestation.
This is where the authorization outcome becomes something the rest of the system can actually use. Instead of leaving the result as an internal yes or no decision Newton turns it into a signed authorization output tied to the transaction and its evaluation.
That signed result matters because a transaction pipeline needs more than a decision. It needs a way to carry that decision into the execution layer.
The attestation is effectively the bridge between authorization and execution.
It tells the next stage that the transaction was evaluated the required policy was applied and the network reached an authorization outcome for that specific action.
Enforcement
The final step is enforcement.
This is where the transaction or smart contract checks whether the required authorization result exists and whether it satisfies the conditions needed for execution. If it does the transaction can proceed. If not the action should not continue.
This is what makes the entire flow meaningful.
Intent creates the proposed action.
Evaluation checks it.
Consensus agrees on the result.
Attestation records the result.
Enforcement makes the result matter.
Without enforcement the earlier steps would still produce useful information but they would not necessarily control execution. Enforcement is what turns authorization from a review process into a transaction gate.
Why this flow matters
What I find useful about Newton’s design is that it gives authorization a real place inside the transaction lifecycle.
A lot of financial control language sounds convincing until you ask where the decision actually happens. Was the rule checked in a frontend? In a backend service? In a manual review step? In a monitoring system after the transaction had already been submitted?
Newton gives a more structured answer.
The transaction is first proposed as an intent.
That intent is evaluated against policy.
The network reaches agreement on the result.
The result becomes a signed authorization output.
Execution depends on that output.
That sequence makes authorization much more concrete. Settlement still records the final state change onchain but Newton adds a decision layer before that point so the transaction can be evaluated and authorized before it becomes final.
To me that is the real significance of the flow.
Newton is not just saying authorization matters.
It is showing how authorization actually happens before a blockchain transaction is allowed to execute.
@NewtonProtocol $NEWT #Newt $VANRY $LAB