VNSIS ArgusRequest access
Menu
Pre-production

See the risk behind the address.

Structural pre-sign intelligence for autonomous wallets.

VNSIS Argus Protocol is a graph-based pre-sign decision system developed by VNSIS Technologies Limited. It evaluates a proposed transaction's counterparty — and the controllers, dependencies and provenance standing behind it — before execution.

The structure behind a counterpartyA counterparty at the centre of an aperture, joined to three relations: the address that deployed it, the authority that can still change it, and the contract it depends on at execution time.DEPLOYED_BYCONTROLLED_BYDEPENDS_ONCOUNTERPARTY

Clean in front, risky behind

An address can pass every direct check and still be the wrong counterparty.

Screening resolves the address in front of you. It does not resolve who deployed it, who can still change it, or what it leans on at execution time. Step through the same assessment Argus performs.

Structural assessment walkthrough — choose a stageIllustrative offline fixture

Agent wallet

Autonomous spender

eip155:…:0x41b…9c2

Proposes ERC-20 approval

BLOCK

Counterparty

Token contract

eip155:…:0x7ac…e41

Direct screening · no match

Deployed by

Deployer address

0x08d…7f0

Also created 3 related contracts

Controlled by

Proxy admin

EIP-1967 admin slot

Can replace the implementation

Depends on

Dependency library

0xc19…a03

Sanctions match · fixture source

Address-level screening stops here

An agent wallet proposes an ERC-20 approval to a token contract. Screening that counterparty address on its own returns no match, so an allowlist or address-level control clears it and execution proceeds.

subject0x7ac…e41
directno match
controlsallowlist · spending cap
outcomeproceeds to signing

Argus resolves what stands behind it

Before the transaction is signed, Argus walks the counterparty's structure: who deployed it, who can still change its code, and what it depends on at execution time.

  • DEPLOYED_BYDeployer also created three related contracts.
  • CONTROLLED_BYA proxy admin can still replace the implementation.
  • DEPENDS_ONA dependency carries a sanctions match in this fixture.
subject0x7ac…e41
directno match
relations3 resolved
coveragefixture source · not operational

Inherited risk changes the verdict

The counterparty's own record is still clean. What it inherits from its dependency is not — and Argus reports that finding as inherited rather than direct, so a reviewer can see exactly where the risk entered.

A Decision Receipt can record this outcome. Issuance is optional at the gate, and the signer used in fixtures is non-operational — it cannot invoke an execution port.

checkDEP_CONTAGION_V1
origininherited
resultFAILED · severity HIGH
viaDEPENDS_ON → sanctions exposure
evidencefixture source · not operational
verdictBLOCK
dispositionDENY

The platform

Four capabilities, one decision.

Argus is not four products. A transaction is decoded once, evaluated against structure and evidence once, and resolved by one versioned policy into one verdict — the receipt is simply that decision, made durable.

01

Decision Engine

Deterministic, versioned verdicts over a canonical transaction. The same intent, policy and evidence always produce the same decision — and the policy version that produced it travels with the result.

02

Graph Intelligence

Deployers, controllers, proxy implementations and dependencies, traversed as a graph. Risk that a counterparty inherits is reported as inherited, never blended into its own record.

03

Coverage Model

Evidence carries its own state. Missing, stale or unavailable intelligence is represented as exactly that, so an absent check can never be rendered as a clean result.

04

Decision Receipts

An optional signed record binding the assessed payload, the policy, the disposition and a commitment to the reasoning — so a decision can be re-examined after the fact.

Decision Receipt

A decision you can re-examine later.

A receipt binds one assessment to the exact payload it was made against, the policy version that produced it, the coverage it relied on and a commitment to its full reasoning. Change any of those after the fact and verification fails.

  • Issuance is optional at the gate — an assessment does not automatically become a receipt.
  • Verification is checked against keys the verifier already trusts, never against the receipt's own claim.
  • A receipt is evidence of a decision, not a bearer token that authorises a different one.
TodayThe signer shipped today is a non-operational fixture; a fixture-signed receipt cannot invoke the Circle execution port. Production KMS/HSM signing is planned, and the current replay store is in-memory rather than crash-safe production infrastructure. The semantics are documented in full on Developers.
Decision Receiptargus-decision-receipt-v1
Payload commitmentsha256:9f2c…4e71
Policydefault@1.1.0
VerdictBLOCK
Execution dispositionDENY
Finding origininherited · not direct
Coverage1 source · fixture · not operational
Reasoning commitmentsha256:1a7d…c204
Signerfixture · non-operational

Illustrative offline fixture. Nothing here represents an operational screening result.

Receipt issuance is optional at the gate.

A fixture-signed receipt cannot invoke an execution port.

Where it fits

Built for systems that sign without a human in the loop.

01

Autonomous wallets

Agents sign faster than anyone can review structure. Argus answers the relational question before the signature, not after the incident.

02

Agentic commerce

Machine-initiated payments to counterparties nobody vetted by hand, bounded by policy that has to be explainable to a risk function.

03

Stablecoin transaction infrastructure

High-volume transfer paths where an address-level allowlist is the only control standing between an agent and an unknown dependency.

04

Wallet and protocol infrastructure

Platforms that execute on behalf of others and need a defensible, versioned reason for every transaction they let through.

Ecosystems

Chain-neutral core. Replaceable everything else.

The decision engine holds no chain knowledge. Ecosystem adapters, intelligence sources and execution integrations all sit behind contracts at the boundary — so a new chain or a new provider is an implementation, not a rewrite, and the decision and its reasoning look the same on either side.

Arc

Integration in progress

Exact ERC-20 decoding, EIP-1967 controller discovery and a Circle Wallets pre-sign gate, all implemented and tested against injected transports and a fake port. No live Arc endpoint is configured and no Circle execution has been performed.

Arc implementation status →

Sui

Architecture ready

The graph model and adapter seams that the Sui work is built on exist and are tested. Programmable-transaction-block pre-sign decoding is not implemented, so there is no complete Sui screening path today.

Sui implementation status →

Complementarity

Argus sits beside execution and screening, not in front of them.

Circle Wallets

Executes the transaction and holds the wallet and key infrastructure. Argus never signs, broadcasts or holds a key.

Circle Compliance Engine

Provides direct compliance and address screening where available — the preferred source of direct-match evidence, not a capability Argus duplicates.

VNSIS Argus

Contributes structural, controller, dependency and inherited-risk evaluation, and binds the decision to the execution-relevant payload and policy.

No Circle integration is live today, and nothing here represents an endorsement or a commercial relationship with Circle.

Who builds this

VNSIS Technologies Limited

Systems · Infrastructure · Security. Argus is built by Evans Isioma Obi, Founder & CTO and sole builder — a background in cybersecurity, application security and infrastructure engineering applied to the one question wallet controls still cannot answer.

Build with structural risk intelligence

Argus is pre-production and in active development. If you run autonomous execution, integrate wallets, or evaluate ecosystems, the useful conversation starts now.