Skip to content

Architecture Explorer

The Architecture Explorer answers the governance question: who can change what? It builds a graph of the protocol's contracts, the roles and owners attached to them, and the control edges between — reading the actual authority slots on the fork rather than trusting the documentation.

It is one of the three workbench surfaces, alongside the Contract IDE and the Auditing IDE. Open it from the Architecture panel of a session at app.trilocore.ai, or drive the same thing from the API:

curl -X POST https://api.trilocore.ai/api/v1/arch \
  -H "Authorization: Bearer $TRILOCORE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "my-protocol", "chain": "eth", "target_ref": "0xYourTargetContract"}'

An architecture is a durable resource: it can be attached to a workspace and project when you create it, and listed, updated and deleted like any other resource. The map itself is produced by a build (POST /api/v1/arch/{architecture_id}/builds), and each build is a resource you can read back.

Reference: Architecture.

The map

The map is the graph the build produces: the protocol's contracts, the accounts and roles that hold authority over them, and the control edges between. Because the authority slots are read from the fork, the map reflects what the deployed protocol actually enforces, not what its documentation claims.

Real targets are not one address. The Explorer works across the whole session scope — the contracts named when the session was opened plus those pulled in from addresses hard-coded in the target's bytecode — rather than one address at a time.

Paths, rules and the trace overlay

From the map you get:

  • Reachability paths — how control flows from an account to a privileged action, including multi-hop routes through proxies and modules.
  • Rules — checks over the map, such as a single key holding sole authority over a critical function.
  • Trace overlay — project an execution onto the map to see which authority edges a transaction actually used. This is the seam with the Auditing IDE: a send you fired from Composer can be laid over the map, connecting what a transaction did to the authority edge that allowed it.

Snapshots and diffs

A snapshot freezes the map at a point in time; a diff compares two of them, so you can see exactly which edges moved after an upgrade or a governance action. Taking a snapshot is a mutating call and requires an Idempotency-Key:

curl -X POST https://api.trilocore.ai/api/v1/arch/{architecture_id}/snapshots \
  -H "Authorization: Bearer $TRILOCORE_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{}'

Next: Auditing IDE for the session the map is built against, or the Endpoint reference to automate any of this.