Contract IDE¶

The Contract IDE is the developer surface: write contracts, compile them, review them, and publish them — with the security tooling in the same workspace rather than a stage you reach at the end.

The thing that makes it different from an editor with a build button is that every workspace is a real git repository. Not a folder that gets exported to git; a bare repo, with branches, tags, protected refs and merge requests, whose history is the same history GitHub sees when you publish.

Create a workspace¶

curl -X POST https://api.trilocore.ai/api/v1/ide/workspaces \
  -H "Authorization: Bearer $TRILOCORE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "my-protocol"}'

Or start from a template instead of an empty repo — list what is available with GET /api/v1/ide/templates, then scaffold into the workspace with POST /api/v1/ide/workspaces/{uuid}/scaffold. Scaffolding writes through the normal commit path, so a template arrives as real history, not as untracked files.

Reference: Workspaces and files.

Files and branches¶

Files are addressed by path within the workspace:

curl -X PUT https://api.trilocore.ai/api/v1/ide/workspaces/{uuid}/files/{rest} \
  -H "Authorization: Bearer $TRILOCORE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content": "// SPDX-License-Identifier: MIT\npragma solidity ^0.8.24;\n"}'

Every write is a commit. Alongside the committed tree there is a draft plane for work in progress, so an editor can save continuously without turning every keystroke into history.

Because it is git underneath, the rest follows: create and delete branches, set branch protection, tag releases. Protection is enforced server-side, so a protected branch cannot be bypassed by a client that decides not to ask.

Compile¶

Compilation is asynchronous. Submit the job, then poll it:

curl -X POST https://api.trilocore.ai/api/v1/ide/compile \
  -H "Authorization: Bearer $TRILOCORE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"workspace_id": "…", "toolchain": "forge"}'

curl -X GET https://api.trilocore.ai/api/v1/ide/compile/jobs/{id} \
  -H "Authorization: Bearer $TRILOCORE_API_KEY"

GET /api/v1/ide/workspaces/{uuid}/languages reports what the workspace looks like — which languages were detected and which toolchain will be selected — and GET /api/v1/ide/toolchains lists the toolchains the service can run.

Language support¶

Language	Detected from	Compiler	Status in the hosted service
Solidity	`.sol`, `foundry.toml`	Foundry (`forge`, with the `solc` it manages)	Available
Vyper	`.vy`, `.vyi`	`vyper`	Available
Rust	`.rs`, `Cargo.toml`	`cargo`	Not enabled — see below

Rust compilation is not enabled in the hosted service

Rust workspaces are detected, and a Rust template is available to scaffold from, but the hosted compiler will refuse a Rust build. The reason is deliberate: cargo build executes build.rs, which is arbitrary code by design, and the container-level isolation used for hosted builds is not a sufficient boundary for that. Enabling it requires a VM-isolated runtime. Treat Rust support as planned, not shipped.

Diagnostics come back in one normalized shape regardless of the compiler — severity, file, line, column, code, message — so tooling built against one language keeps working for the next.

Reference: Compilation and integrations.

Compiler output

The compile job reports success, diagnostics and a manifest of what was built. Direct download of the produced artifact is not yet exposed through the public API.

Review¶

Review is a first-class part of the workspace, not a GitHub round trip.

Merge requests — open one between branches, comment on it, record reviews, attach status checks, and merge when they pass.
Annotations — attach a note to a specific place in the code, thread comments under it, and move it through a status. This is the seam between the two IDEs: something found in an audit becomes an annotation on the exact line that caused it.
Audits — a workspace audit collects annotations and findings, exposes the tree and blob at the reviewed revision, holds evidence, and closes with a status.

Findings can be exported as SARIF, per workspace or per audit, which is what a code-scanning integration consumes.

Reference: Review, audits and evidence.

Evidence¶

Evidence is the auditable half of a review: an artifact attached to an audit, signable, verifiable, and subject to a retention policy. Signing produces a record that the evidence existed in that exact form at that time; verification re-checks it later. Retention is explicit, so nothing is silently discarded and nothing is silently kept forever.

Publish to GitHub¶

Because a workspace is a git repo, publishing is a genuine push of the full commit history — not a snapshot export. Connect the repository once, then push:

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

The connection is owner-only and the token is held encrypted; the push URL is rebuilt from the validated repository name rather than taken verbatim from the client. Publishing is a mutating call and requires an Idempotency-Key — as does POST /api/v1/ide/workspaces/{uuid}/bindings/push.

Members and access¶

Workspace membership is explicit, with roles that decide who can write, who can merge, and who can administer the connection to GitHub. The workspace audit log records what was done and by whom.

Where this meets the Auditing IDE¶

The two surfaces share a workspace. In practice that means:

A contract you are writing can be compiled here and then examined on a fork in the Auditing IDE.
A finding raised against a deployed contract can come back as an annotation on the line responsible, tracked to a status.
Both trails land in the same workspace activity, so the record of an engagement is one story rather than two.

Next: Core concepts for workspaces, projects and findings, or the Endpoint reference for everything above in detail.