> For the complete documentation index, see [llms.txt](https://docs.trac.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.trac.network/documentation/developers/mainnet/dapp-developer-guide/wallet-and-dapp.md).

# Wallet and dApp

## Wallet + dApp Integration

This page focuses on “Ethereum-style” connectivity:

* dApps discover a `trac-peer` via a URL
* dApps fetch schema + context from the peer RPC
* wallets sign (they do not run peers)

### What a wallet signs (contract tx)

A `trac-peer` contract transaction is an MSB operation of `type = 12`.

The wallet signs a 32-byte hash (`tx`) computed from:

* MSB tx context (from `GET /v1/contract/tx/context`)
* the typed command `{ type, value }` (hashed as `ch`)
* a nonce (`in`)

Important: this is **not** a TNK transfer. There is no `to`/`amount` field in a contract tx.

Users can still pay MSB fees for the tx.

### Required RPC reads for signing

1. Contract schema (what exists):

* `GET /v1/contract/schema`

2. Nonce:

* `GET /v1/contract/nonce`

3. Tx context:

* `GET /v1/contract/tx/context`

This returns (names as used in MSB payloads):

* `networkId`
* `txv`
* `iw`
* `bs` (subnet bootstrap)
* `mbs` (MSB bootstrap)
* `operationType` (currently `12`)

### Wallet signing payload shape (recommended)

The wallet extension API used in this workspace exposes `window.tracnetwork`.

For contract tx signing, a typical payload is:

```json
{
  "prepared_command": { "type": "catch", "value": {} },
  "nonce": "<hex32>",
  "context": {
    "networkId": 918,
    "txv": "<hex32>",
    "iw": "<hex32>",
    "bs": "<hex32>",
    "mbs": "<hex32>",
    "operationType": 12
  }
}
```

The wallet should:

* compute `ch = blake3(JSON.stringify(prepared_command))`
* compute `tx = blake3(createMessage(networkId, txv, iw, ch, bs, mbs, nonce, operationType))`
* sign `tx` bytes with the active account’s private key

The dApp should also read the user’s public key (hex) via `window.tracnetwork.getPublicKey()` and use it as the `address` field when calling `POST /v1/contract/tx`.

### Simulate first, then broadcast

Recommended client flow:

1. submit the signed payload with `sim=true`
2. if OK, submit the same payload with `sim=false`

Both are `POST /v1/contract/tx`.

If `sim=true` fails due to missing MSB entry or insufficient fee balance, do not broadcast.

### Security model notes

* The peer validates signatures and MSB constraints. A dApp cannot “swap” the command type/value after the wallet signs, because that changes `ch` and `tx`.
* A contract tx cannot transfer TNK to a recipient. If you ever add native transfer support, it must be a different MSB operation type and the wallet UI must surface `to/amount`.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.trac.network/documentation/developers/mainnet/dapp-developer-guide/wallet-and-dapp.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.