Product
One decision, made the same way every time.
VNSIS Argus Protocol is a graph-based pre-sign decision system developed by VNSIS Technologies Limited. It decodes what is about to be signed, resolves the structure behind the counterparty, and resolves both into a verdict a reviewer can re-derive.
The path a transaction takes
Six stages, no hidden steps.
- Intent
A wallet or service proposes a transaction it is about to sign.
- Canonical transaction
Decoded exactly. Anything unrecognised is reported as unrecognised, never guessed.
- Structural graph
Deployers, controllers, proxy implementations and dependencies resolved as relations.
- Coverage-aware policy
A versioned pack weighs findings against the state of the evidence behind them.
- Verdict
ALLOW, WARN, REQUIRE_APPROVAL or BLOCK, with the full reasoning attached.
- Execution disposition
At an execution boundary: EXECUTE, HOLD, DENY or REFUSE.
Canonical transaction model
Decode exactly, or say you couldn't.
Argus reduces a chain-specific intent to a canonical representation the engine can reason about without knowing which chain it came from. ERC-20 transfer, approve and transferFrom calls are decoded field by field.
A call shape the decoder does not recognise is returned as unrecognised. It is never partially decoded and never approximated, because a half-read transaction is a worse input than an admitted unknown.
Deterministic decision engine
The same inputs always produce the same verdict.
Policy packs are versioned and the version travels with the result. Two runs over the same intent, the same graph and the same evidence produce the same verdict — which is what makes a decision auditable months later rather than merely plausible at the time.
Reconciliation of evidence is order-independent: the sequence in which sources arrive cannot change the outcome.
Graph traversal and inherited risk
Risk that arrives through a relationship is labelled as such.
Argus walks the relations around a subject — who deployed it, who can change it, what it depends on — and propagates findings along them. A counterparty with a clean direct record can still fail because of what stands behind it.
- Direct and inherited findings stay distinguishable in the result, never merged into one score.
- Traversal is cycle-safe and bounded, so a circular dependency cannot stall or double-count.
- An incomplete crawl reports low confidence rather than a clean pass — an unindexed branch is not evidence of absence.
- DEPLOYED_BY
- Provenance: the address that created the contract, and what else it created.
- CONTROLLED_BY
- Authority: proxy admins and upgrade paths that can still change the code being called.
- DEPENDS_ON
- Execution surface: contracts this one calls into when the transaction runs.
Evidence and coverage
An absent check is not a pass.
Most of the damage in this category comes from one small modelling mistake: letting a failed, missing or stale lookup collapse into the same value as a clean result. Argus separates them at the type level.
Evidence carries the source that produced it, when it was checked, how long it stays valid, and whether that source is operational at all. A fixture source cannot clear a subject. A stale result cannot masquerade as a fresh one. A provider outage surfaces as an outage.
ReasonTrace
The reasoning, not a score.
Every verdict carries the checks that ran, what each concluded, the origin of each finding, and the gaps in its own inputs. The trace names what Argus could not establish as plainly as what it could.
That trace is committed to a digest, so the reasoning behind a decision can be shown to be the reasoning that was actually used.
Decision Receipts
A decision, made durable.
A gate-created assessment can be issued as a signed receipt binding the assessed payload, the policy and execution-profile versions, the verdict and disposition, the coverage consulted and a commitment to the reasoning.
- Issuance is optional: an assessment does not automatically become a receipt.
- Only an assessment the gate itself created can be issued as one.
- Verification is performed against signer keys the verifier already trusts.
- Tampering with any committed field invalidates verification.
Illustrative offline fixture.
Issuance is optional at the gate.
A fixture-signed receipt cannot invoke an execution port.
Execution boundary
Argus withholds. It never signs.
At the boundary, a verdict becomes a disposition and the payload commitment is recomputed and compared immediately before anything is forwarded for execution. A payload that changed after assessment is refused rather than executed.
Argus holds no keys, signs nothing and broadcasts nothing. Its only power is to decline to pass a transaction on.
Four dispositions
- EXECUTE
- The decision and the payload both still hold.
- HOLD
- Policy requires an approval step before execution.
- DENY
- The engine decided against this transaction.
- REFUSE
- Not a risk decision: the chain of custody between decision and action broke — a mutated payload, an unrecognised signer, a replayed receipt.
See it applied to your surface
Solutions covers where Argus sits for autonomous wallets, agentic commerce, stablecoin flows and infrastructure platforms.