An address marked as risky can be disregarded in just a few seconds. The user creates a new wallet, switches to an address with no transaction history, and continues operating as if nothing happened.
That’s a pretty obvious weakness of systems that assess risk only based on onchain data.
A new wallet is usually almost completely empty. It hasn’t interacted with suspicious protocols, hasn’t received funds from a sanctioned address, and hasn’t left enough data for analysis tools to determine how dangerous it is. If you look only at the wallet address, someone with a bad history can still look like a new user.
Magic Labs Risk Scoring Data Oracle, integrated into the policy of #Newt Protocol, aims to address this gap by scoring both wallets and email.
At first, putting email into an onchain transaction control system may sound a bit strange. However, it is more reasonable when you look at how Magic builds embedded wallets.
Many Magic users do not create wallets in the traditional way using a seed phrase. They sign in with email, create the wallet in the app, and also use email to restore access. As a result, the email and wallet address are linked right from the account layer.
This creates a signal that normal blockchain analysis does not have.
A person could create dozens of new wallets almost for free, but continuously building clean email accounts that are unrelated to any wallets that have been flagged would be harder. If an email has previously been linked to a high-risk wallet, switching to a new wallet may not erase all traces.
According to information released, Magic’s system uses data accumulated over roughly seven years, covering more than 50 million wallets, and combines OFAC sanctions data with several other public sources.
Developers can feed these risk scores into Newton’s policy to determine whether an action should be executed or not.
For example, an AI trading agent could be blocked before it sends assets to an address related to a sanctions order. A stablecoin issuer might require more thorough checks when users mint or redeem large amounts. An RWA platform could also set different policies based on the transaction value, wallet score, and email score.
The key point is that a risk score should not be viewed as an absolute judgment.
A wallet that has interacted with a suspicious address is not necessarily controlled by a bad actor. Users might accidentally receive junk tokens, get hacked, or use a shared email within an organization. If you need only a bad signal to instantly reject a transaction, the system is very prone to generating false positives.
The value of @NewtonProtocol lies in its ability to combine multiple conditions rather than relying on a simple blacklist.
Small transactions might only need a wallet check. Large transactions may require an additional email score or further verification. Unclear cases can also be routed to a manual review process instead of being blocked immediately.
That said, this approach still has limitations.
An email score only matters when the wallet is created or managed through Magic’s infrastructure. If a user uses a completely independent wallet, keeps the private key themselves, and has never linked an account to Magic, the oracle will have no email data to verify.
So this is not a solution for identifying who is behind every wallet on the blockchain. It only adds an extra layer of signal for the group of users who have passed through Magic’s account system.
This design also raises privacy questions.
When a wallet’s risk is linked to email, the policy starts to use data closer to the user’s identity than in the traditional DeFi model. That might be appropriate for stablecoins, RWAs, or high-value transactions, but it could be excessive for the small-scale activities of typical retail users.
There is no policy that fits all cases.
A notable point is that the builder can select the data sources, risk thresholds, and application conditions. Instead of forcing every transaction to go through the same level of checks, each application can strike a different balance between privacy and risk-control requirements.
A new wallet may have no history.
But the person behind it may not have truly started from scratch.
And that’s why Magic’s Risk Oracle doesn’t just look at where the assets are currently located—it also checks the account layer that created the wallet.