VibeGuard
VibeGuard

Ecosystem Primitives & Cross-Stack Integration

How VibeGuard AI combines Sui ecosystem primitives with core stack layers

System Design

Architecture Overview

User (Google OAuth)
zkLogin (ephemeral burner wallet)
Sponsored Transaction (gasless)
Sui (ReputationRegistry)
Walrus (threat evidence)
Nautilus (verified compute)
Seal (agent config protection)

Stack Comparison

Core Stack vs Ecosystem Primitives

Core Stack

  • Sui: Trusted state
  • Walrus: Decentralized storage
  • Seal: Protected access
  • Nautilus: Verified compute

Ecosystem Primitives

  • zkLogin: OAuth wallet
  • Sponsored Tx: Gasless execution
  • Enoki: Not used
  • DeepBook: Not applicable

Authentication

zkLogin Integration

Why zkLogin?

  • ✓ Zero wallet friction for community reporting
  • ✓ Privacy-preserving (OAuth not linked publicly)
  • ✓ Self-custody ephemeral keypair
  • ✓ Combined with sponsored transactions

Design Decision

Why Native zkLogin (Not Enoki)?

Our Choice: Native zkLogin with custom sponsored transaction flow

  • ✓ Full control over security reporting UX
  • ✓ Direct Sui primitive integration
  • ✓ Simpler architecture for B2B product
  • ✓ No external service dependencies

Product Context: VibeGuard is B2B security infrastructure. Primary users are wallet providers consuming threat intelligence. Community reporting is secondary where current UX is acceptable.

Scope Clarification

Why No DeepBookV3?

VibeGuard is not a trading product. We provide transaction security analysis and threat intelligence. No order flow, no market matching, no exchange functionality. DeepBook would be architecturally incorrect.

Access Control

Seal Access Control

Pattern 4 — Secure Input Layer for Verified Compute

The proprietary threat-agent configuration (scoring weights, risk thresholds, heuristic rules) is encrypted under a PCR-based Seal policy. Only an enclave whose PCR measurements match the registered policy can decrypt and load the configuration.

  • ✓ Secret encrypted under Seal policy ID 0x00 via scripts/seal-setup.ts
  • ✓ Approved enclave registered via seal_enclave::register_enclave() — stores PCRs + Ed25519 pubkey on-chain
  • ✓ Seal key servers verify PCR measurements before returning key shares
  • ✓ Enclave signs output: pkg_bytes(32) + blob_bytes + timestamp_ms LE64
  • seal_enclave::verify_and_report() verifies Ed25519 signature before emitting ThreatVerified

EnclaveConfig Object (registered PCRs + public key)

0x2ca9a5fe17b6f53259ccf2c793268a82bd04e3d82fb3bc482a4dbb740400c502

Verified Compute

Product Pattern: Verified-Compute

Module 5 Pattern 3: Verified-Compute Product

  • ✓ Entry: zkLogin for community reporting
  • ✓ State: Sui (ReputationRegistry)
  • ✓ Compute: Nautilus (Rust TEE threat detection inside AWS Nitro Enclave)
  • ✓ Access: Seal (threat-agent config encrypted under PCR-based policy — inaccessible outside approved enclave)
  • ✓ Verification: ThreatVerified event emitted on-chain after Ed25519 signature check

On-Chain Evidence

Live Proof Transactions

Production Enclave Registration

3QNgqGy5uMYdzuEjitbjkkd8s6LyWeqD9CJwptYkoZPb

Atomic Threat Report (ThreatVerified + ThreatReported)

6qBWeX62UUzxm6GromBfo6fwXsNNNYjh9WbzfTrJqYDk