Team Overview

Acceso is built by a small, focused team of 4–5 core members.

Each member owns a critical platform domain.

We keep the team compact to maintain velocity and accountability.

The team is organized by system ownership.

Each role maps to clear responsibilities.

Core team structure

• Backend Infrastructure Engineer (United States) Owns core API architecture, data aggregation pipelines, scalability design, and production reliability.

• Blockchain & Protocol Engineer (United States) Responsible for Solana integrations, DeFi analytics logic, Polymarket adapters, x402 payment flows, and ZK infrastructure.

• Frontend & Dashboard Engineer (Europe) Builds the dashboard application, developer tooling, usage analytics UI, and internal management interfaces.

• Product & Systems Architect (Remote) Coordinates system-level design, feature alignment, long-term evolution strategy, and documentation standards.

• Community & Social Manager (South Asia) Handles community communication, feedback loops, social updates, and ecosystem coordination.

Operating principles

• Clear ownership per system domain.

• Production-first engineering habits.

• Additive evolution and backward-compatible changes where possible.

• Operational discipline and measurable reliability.

Why identities are not fully public (yet)

Acceso was intentionally built quietly over an extended period.

We are not optimizing for founder visibility.

We are optimizing for stable infrastructure.

Reasons for limited disclosure:

• Security: public identity increases targeted social-engineering and impersonation risk.

• Operational focus: early attention often creates hype-driven pressure.

• Privacy: contributors retain personal privacy while the platform matures.

This is a deliberate operating choice.

It is not a request for trust without evidence.

How to evaluate trust without identities

Use objective signals:

• Public documentation and consistent platform behavior.

• Verifiable on-chain actions where applicable (for example, token locks).

• Clear security posture and key-handling practices.

• Stable APIs and backward-compatible evolution.

• Support responsiveness and transparent incident handling.

What we will not do

• Ask users to trust private claims.

• Hide allocation changes behind vague statements.

• Use unofficial channels as sources of truth.

As the platform matures, we plan to increase public-facing communication gradually.

We will do it responsibly.