The project already has a smart contract for distributing tokens to eligible users. The missing piece is a way to determine whether a recipient is sanctioned and enforce that decision before the reward is irreversibly sent.
01 - The challenge
A project programmatically distributes tokens to eligible users through a smart contract. However, the distribution contract has no built-in way to screen recipients for sanctions compliance. Regulators expect any distribution to comply with applicable sanctions.
The requirement is one line: do not send rewards to sanctioned wallets.
The distribution contract was built to answer a different question, and the team has no appetite for standing up the compliance stack of an exchange.
What’s missing is a way to have a sanctions policy enforced before any tokens are sent to a user.
02 - The control gap
The sanctions data comes from an offchain source. The payout happens onchain. Nothing currently connects the two at the moment the payout is decided.
03 - The solution
A Newton Policy brings the sanctions rule and the sanctions data together and enforces them at the moment of the claim. For this case study, the designated addresses from the published sanctions source are provided to the policy as a snapshot, allowing the verdict to be proven before the tokens are released.
04 - How Newton Works
Newton adds one step to a transaction: a policy check, before the money moves.
When a claim comes in, it goes to Newton's network. A group of operators each check it against the rule the project set.
Once enough of them agree on the answer, their approvals are combined into a single signature, an attestation that the network checked this transaction against this rule and returned a verdict. That attestation travels back to the smart contract, which reads it and either releases the tokens or doesn't.
The rule itself is written in Rego, a policy language large enterprises already use for compliance. Every operator evaluates the identical rule against the identical data, so they all reach the same verdict.
In this case study, the sanctions source is offchain, while the designated Ethereum addresses from the sanctions source are provided to the policy as its parameters. Every operator reads the same snapshot from the same source.
05 - Configure the policy
For this case study, the Newton Policy is configured around three things: the sanctions data, the rule, and the contract that enforces the result.
Choose the data: The policy for this case study uses an open source published list of designated Ethereum wallets.
Write the rule: The rule is written in Rego and evaluates the snapshot of designated addresses. A recipient on the list means a blocked claim. Anything else is allowed. If the list is missing or empty, the default is to refuse.
Deploy it: The policy is published and gets its own address. The smart contract points at that address and checks incoming attestations against it. The rule and the contract stay separate, so the rule can change without redeploying the contract or touching the application logic underneath.
Once the policy is deployed, it sits in the path of every reward claim. The distribution contract can continue handling the claim as before, but the tokens are only released after the policy returns a valid result.
06 - A clean wallet claim
A user submits a reward claim. The recipient address is evaluated by the Newton Policy, and the operator quorum signs the policy result. No sanctions list match was returned, so the claim executed.
07 - A sanctioned wallet claim
A user submits the same claim from a wallet that appears on the sanctions list. The policy evaluation fails, so the transaction is blocked.
08 - The Attestation
Every decision, allowed or blocked, becomes a public record on the Newton Explorer. Each record shows the wallet, the rule that was applied, the verdict and the time.
This is what a project can hand to a regulator, an auditor or a partner. Both the approved claim and the blocked one appear under the same rule, so anyone can verify the control was actually running.
09 - Scope and limits
This is an example of a sanctions screening control, not a complete sanctions compliance program.
- The screening list in this demonstration is a snapshot of the designated addresses used by the policy, not a live feed.
- It does not automatically pick up a designation made after the snapshot.
- This demo runs on Ethereum Sepolia, a test network.
10 - Outcome
The project adds a sanctions control to its rewards without changing how the distribution works.
- The published sanctions list supplies the sanctions data.
- The policy defines the rule: a designated recipient means a blocked claim.
- Newton evaluates the claim and returns an attestation before the payout.
11 - Takeaway
A sanctions signal is only worth having if you can act on it. This puts a control between the signal and the payout.
Try it yourself → Newton Sanctions Demo