# AEREDIUM extensions (aer\_\*)

AEREDIUM adds a small `aer_*` namespace for features that don't exist on Ethereum: TEE attestations, ZK-STARK execution proofs, Bitcoin anchoring, and TSS-USIG enclave health.

You don't need any of these to build a normal dApp — but they're how you verify the chain's integrity from the outside.

## Validator & TEE

### `aer_getValidatorAttestation`

Returns the TEE attestation document for a validator.

```json
{ "jsonrpc": "2.0", "id": 1, "method": "aer_getValidatorAttestation", "params": ["validator-id"] }
```

Response includes the attestation type (`nitro`, `sgx`, `sev-snp`), the PCR0 measurement (proves which code is running), the public key, and the expiry.

### `aer_getTEEStatus`

High-level TEE health for all validators in the active set.

```json
{ "jsonrpc": "2.0", "id": 1, "method": "aer_getTEEStatus", "params": [] }
```

### `aer_getTSSUSIGStatus`

Status of the TSS-USIG anti-equivocation counter for the validator group(s) — useful for monitoring and audit.

```json
{ "jsonrpc": "2.0", "id": 1, "method": "aer_getTSSUSIGStatus", "params": [] }
```

## ZK-STARK execution proofs

Every block has a verifiable proof of correct EVM execution. These methods let you fetch and verify them.

### `aer_getAttestation(attestationId)`

Get a proof by its ID.

### `aer_getAttestationByBlock(blockNumber)`

Get the proof covering a specific block.

```json
{ "jsonrpc": "2.0", "id": 1, "method": "aer_getAttestationByBlock", "params": ["0x12a05f"] }
```

### `aer_getLatestAttestation`

Most recent generated proof.

### `aer_getProofStatus(proofId)`

Generation status of a proof: `pending`, `proving`, `verified`, `failed`.

### `aer_getProofBatch(fromBlock, toBlock)`

Batch of proofs for a block range — useful for bridges and light clients catching up.

### `aer_verifyExecution(blockNumber)`

Server-side full verification: fetches the proof, replays the witness, returns `true` / `false`. For independent verification, use `getAttestationByBlock` and verify offline with the STARK verifier.

## Bitcoin anchoring

Periodic block-state commitments are anchored to Bitcoin via OP\_RETURN. Once a Bitcoin transaction is buried under enough confirmations, the corresponding range of AEREDIUM blocks is unrollable even by the entire validator set.

### `aer_getBitcoinAnchor(anchorId)`

Anchor record by ID. Returns the AEREDIUM block range, the Bitcoin tx hash, and the current confirmation count.

### `aer_getBitcoinAnchorByBlock(blockNumber)`

The anchor record (if any) covering a given AEREDIUM block.

### `aer_getLatestAnchor`

Most recent anchor.

### `aer_getAnchorStatus(anchorId)`

Lightweight status query: `pending` (broadcast but unconfirmed), `confirming` (1–5 BTC confirmations), `final` (≥ 6).

## Settlement

### `aer_getSettlementStatus(txHash)`

Cross-chain settlement status for a transaction that targets an external L1 / L2.

## Subscribing to anchor events

Over WebSocket, subscribe to anchor confirmations as they happen:

```json
{ "jsonrpc": "2.0", "id": 1, "method": "eth_subscribe", "params": ["aer_anchorConfirmed"] }
```

You'll receive a notification each time a Bitcoin anchor reaches `final` status (≥ 6 confirmations).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://aeredium.gitbook.io/developer.aeredium.io/json-rpc-api/aeredium.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.