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