Developers
The architecture, and what it does not do yet.
VNSIS Argus Protocol is a graph-based pre-sign decision system developed by VNSIS Technologies Limited. This page is the technical surface: how the parts are separated, what the trust model actually guarantees, and where the honest edges are.
Architecture
A core that knows nothing about chains, and boundaries that do.
Everything chain-specific, provider-specific or execution-specific sits behind a contract at the edge. That separation is what makes a second ecosystem an implementation rather than a fork.
Canonical subjects, evidence contracts, policy evaluation and ReasonTrace. Imports no chain SDK and reads no chain-specific field — an architecture test fails the build if it ever does.
Deployer, controller and dependency relations, with cycle-safe traversal, blast-radius calculation and inheritance that keeps direct and inherited findings distinct.
Chain-specific decoding and discovery behind a fixed contract. The EVM adapter performs exact ERC-20 decoding and EIP-1967/1167 discovery; transports are injected, never constructed inside the adapter.
Any source that can produce canonical coverage evidence. The engine consumes the evidence contract, not a provider type, so substituting a source does not change decision logic.
The wallet or custody platform that actually executes. Argus composes an intent, decides, recomputes the payload commitment and either forwards or withholds.
Capability vs coverage
Two different kinds of “we don't know”.
Capability describes whether a lookup could be performed at all: an adapter may not support it, a provider may be unreachable, a credential may be missing. The result type has two states — a value, or an unavailability with a reason. There is no third state that hands back a number alongside a warning.
Coverage describes what an actual check established about a subject: checked with no match, checked with a match, stale, never checked, or not applicable. Only one of those clears a subject, and only when the source that produced it is operational.
Collapsing those two into a single boolean is the specific mistake this engine is built to make impossible.
Decision Receipt trust model
- Issuance is optional and gated
- Only an assessment created by the gate itself can be issued as a receipt. A reconstructed or deserialized object cannot.
- Trust is the verifier's, not the receipt's
- Verification checks the signature against keys the verifier already holds. A receipt's own claim about its signer proves nothing.
- Evidence, not authorisation
- A valid receipt records what was decided. It does not authorise a different payload, a replay, or a stale decision.
- Fail closed on the unknown
- An unrecognised schema version, algorithm or signer id is refused rather than accepted with a warning.
Replay and recovery
What happens if the process dies mid-call.
Receipt submission claims the receipt atomically before the execution port is invoked, and a second claim refuses — proven against both sequential and concurrent duplicate submission.
Claiming before the call is a deliberate fail-closed choice. If the process crashed after the claim but during the external call, the receipt stays claimed while the transaction's outcome is unknown. Recovery reconciles through the execution provider's own idempotency key and transaction status — never by reusing the receipt.
- Sequential duplicate submission: refused.
- Concurrent duplicate submission: at most one execution-port invocation.
- Mutated payload after issuance: refused on a recomputed commitment.
- Caller-supplied coverage cannot replace the coverage bound to the assessment.
Production readiness
What is proven, what is in progress, what is absent.
Everything below is assessed against the same five-state vocabulary the ecosystem pages use, so “tested against fixtures” and “working against a live endpoint” never share a label.
- Chain-neutral decision engineProven offline
Evaluated end to end against a fixture chain that does not exist, proving the engine holds no hidden chain dependency.
- Coverage and evidence contractProven offline
Five-state coverage model with one clearing state; a fixture source is machine-readably non-operational and cannot clear a subject.
- Deterministic policy packsProven offline
Versioned packs; evidence reconciliation is order-independent and produces byte-identical results across orderings.
- ReasonTrace and input gapsProven offline
Every verdict carries its checks, origins and the gaps in its own inputs, committed to a deterministic digest.
- Exact EVM transaction decodingProven offline
ERC-20 transfer, approve and transferFrom decoded field by field; unrecognised shapes reported as unrecognised.
- EVM structural indexerProven offline
EIP-1967/1167 discovery against injected transports. It has never been run against a live RPC endpoint.
- Pre-sign execution gateIntegration in progress
Payload commitment, gate-created assessment provenance and disposition profile, all exercised against a fake execution port.
- Decision Receipt issuance and verificationIntegration in progress
Issue, verify, mutation refusal and replay refusal are implemented and tested. The signer is a non-operational fixture.
- Operational screening coverageNot available
No intelligence provider is connected on any chain. Every real evaluation reports the gap rather than clearing a subject.
- Production receipt signingPlanned
A KMS/HSM-backed signer is specified against the same interface. No implementation exists.
- Durable replay storagePlanned
The replay claim runs against an injected atomic store. No durable, crash-safe production implementation is shipped.
- Sui PTB pre-sign decodingNot available
Programmable-transaction-block decoding is not implemented, so there is no Sui pre-sign screening path.
Verification posture
Claims are held up by tests, not adjectives.
The repository runs a single gate over build, typecheck, lint, the full test suite, whitespace integrity and a clean working tree. Architecture tests enforce the boundaries described above — that the core imports no chain SDK, that a fixture chain can never be selected in production composition, and that the engine is exercised end to end against a chain that does not exist.
The codebase has been through independent review cycles, with the corrections integrated rather than argued away.
Not published
- No published API documentation, because there is no public API yet.
- There is no public source repository link to give.
- No dashboard, console or sign-in destination exists.
- Technical diligence material is shared directly on request.
Take it apart
For integration or diligence conversations, the architecture, the claims register and the test evidence are available directly.