Overall Architecture

System shape

You integrate with stable, versioned APIs. Internals can evolve without client rewrites.

Acceso is a service-oriented platform with one public entry point and many internal domain services.

This diagram is the canonical, full-fidelity view. The High-Level System Overview uses a simplified sketch on purpose.

Client (REST / SDK / WS / Webhooks)
  |
  | 1) Auth + quotas + validation + routing
  v
API Gateway (stateless, horizontally scaled)
  |
  | 2) Domain call (bounded responsibility)
  v
Internal Services
  - Solana Service
  - DeFi Analytics Service
  - Polymarket Service
  - ZK Proof Service
  - x402 Payment Service
  - Notification Service
  |
  | 3) Upstream reads / derived datasets
  v
Upstreams + Shared Infra
  - Solana RPC providers
  - Protocol adapters / parsers
  - Redis cache (shared)
  - Metrics + logs + tracing

Key design goals

• Stable external contracts. Versioned endpoints and consistent schemas.

• Domain isolation. Each service owns its protocol logic and failures.

• Operational safety. Timeouts, retries, quotas, and structured errors.

• Performance by default. Cache-first reads where safe.

• Additive evolution. New capabilities ship without breaking old clients.

Boundary model (what changes fast vs slow)

Acceso separates client-facing contracts from internal implementation details.

External boundary (slow-changing)

• REST APIs (versioned)

• WebSocket streams

• Webhooks

• SDK surface aligned to the above

Contract changes are controlled and backward compatible.

Internal boundary (fast-changing)

• RPC providers and failover logic

• Protocol parsing and adapters

• Cache strategy and derived views

• Cryptographic engines and circuits

These can change without client impact.

Clients never talk directly to RPC nodes or protocol-specific APIs. They always go through Acceso’s normalized contracts.

Core architectural decisions (and what they unlock)

• Single gateway

  • Consistent auth, quotas, and error formats.

  • Central place for request tracing and telemetry.

• Stateless edge

  • Scale horizontally behind a load balancer.

  • Safe rolling deploys with minimal coordination.

• Service-per-domain

  • Faster iteration per domain.

  • Clear ownership and blast-radius control.

• Normalization layer

  • One naming and type system across vendors and venues.

  • Less client-side parsing and glue code.

Invariants (promises the platform tries to keep)

• Requests are traceable end-to-end via a request identifier.

• Failures return structured errors.

• Normalized outputs avoid upstream-specific quirks.

• Internal service failures should not cascade globally.

Where to dive deeper

• Follow the step-by-step flow in Request Lifecycle.

• Learn responsibilities per service in Service Architecture.

• Understand throughput patterns in Data Flow, Caching & Performance.