# The bindings escape hatch
Documentation: next (source: develop).

Install the preview: `pnpm add @aephia/atlas-kit@next`. These docs follow develop and may include changes not yet published to npm.

> The raw generated SAGE C4 client, what you give up by using it, and when reaching for it is the right call.

Markdown source of https://develop.atlas-kit-docs.pages.dev/concepts/bindings/ — see https://develop.atlas-kit-docs.pages.dev/ai/ for the full machine-readable surface.

`@aephia/atlas-kit/bindings` re-exports the generated `@staratlas/dev-sage` client
unchanged. It exists so that a missing feature in this SDK is an inconvenience
rather than a wall.

:::caution[Use the upstream reference for bindings]
Everything under `bindings` is generated from the on-chain program by Codama and
is owned upstream. It can change when the bindings are regenerated. Read the
[`@staratlas/dev-sage` package](https://www.npmjs.com/package/@staratlas/dev-sage)
for that surface.

Every Atlas Kit entry other than `bindings` is documented from its source in
[the reference](/reference/).
:::

## What you get

The full generated surface: account decoders, instruction builders, PDA
helpers, and the types they use — roughly 48 account types and 239 instructions
at the pinned version.

## What you give up

Reaching into `bindings` steps outside every guarantee the rest of the SDK
makes:

- **No validation.** The SDK checks program ownership, discriminators, data
  shape, and minimum length before decoding. Generated decoders do not, so a
  wrong or truncated account decodes into plausible nonsense instead of raising.
- **No caching.** Reads go straight to your RPC every time, with no shared
  snapshot and no provenance.
- **No stable types.** Generated types change when the bindings are regenerated
  for a new program version. The SDK's own snapshot types are insulated from
  that; yours will not be.
- **No SDK-level safety guarantee.** This escape hatch only exposes the pinned
  generated client, including all of its instruction builders. It does not add
  validation, planning, signer handling, or submission policy; code using it
  owns those decisions directly.

## When to use it

When you need an account type or field the SDK has not adapted yet, and you
would otherwise be blocked. That is the whole purpose, and using it for that is
not a workaround — it is the designed path.

If you find yourself using it repeatedly for the same thing, that is a signal
the SDK should adapt it properly. Open an issue describing the account and the
read you need.

:::game[Why some accounts need discovery]
Several SAGE account types have no derivable address — the Game account,
crafting processes, claim stake instances, and loot among them. Their addresses
are assigned at creation rather than computed from known inputs.

That is why some lookups need a known address, a scan, or an indexer, while
others can be derived on the spot. It is a property of the game's data model,
not a gap in the SDK.
:::