# Subnet creation and deployment

### Step 1: Subnet creation

To create a subnet, first connect to the `bitcoin-ipc` container running:

```bash
docker exec -it bitcoin-ipc bash
```

Then run:

```bash
# from inside the container
/usr/local/bin/bootstrap_subnet_a_from_container.sh
```

{% hint style="warning" %}
The script outputs the `SUBNET_ID` of the newly created subnet, make sure you export it using the printed command!
{% endhint %}

This is the `scripts/bootstrap_subnet_a_from_container.sh` script from the `bitcoin-ipc` repo, which has been mounted in the container for convenience. It does the following:

1. It submits to bitcoin-core all required transactions to create a subnet and to join and fund four validators.  
2. It updates the `config.json` files of all validators in the `/root/.ipc` directory of the container. 
3. It prints, among others, the `SubnetID` of the newly created subnet — it is a good idea to export it to an env variable.

{% hint style="info" %}
Before running the previous command, you can start terminal(s) watching the logs of the Monitor and Provider for some validators, as explained in [Optional: Helper scripts](/ipc-btc-scaling-docs/user-guide-for-using-subnets/optional-helper-scripts.md). This way you can see what is being writen and read from Bitcoin in real time.
{% endhint %}

### Step 2: Validator deployment

The subnet has now been created and sufficiently many validators have joined. We can start the validators by running:

```bash
# from inside the container
/usr/local/bin/spin_up_subnet_a_from_container.sh $SUBNET_ID
```

where `SUBNET_ID` indicates the subnet from the first step.

This is the `/scripts/spin_up_subnet_a_from_container.sh` script from the `bitcoin-ipc` repo, which has been mounted in the container for convenience. Even though it is run inside the container, the command is handled by the docker daemon on your host machine. It does the following:

1. It starts twelve Docker containers (three for each validator: `fendermint`, `cometbft` , and `ethapi`) on your host.
2. It starts a Relayer for each validator, with log files stored in  `/root/logs/` in the container. See [Optional: Helper scripts](/ipc-btc-scaling-docs/user-guide-for-using-subnets/optional-helper-scripts.md) for more information on the log files.

{% hint style="info" %}
**About the Relayer and Checkpoint messaging**

In IPC a *checkpoint message,* also called a *bottom-up message*, contains:

1. release operations from the child (an L2 subnet) to the parent (Bitcoin L1)
2. transfer operations from the child to another subnet,
3. the actual checkpoint hash.

IPC requires a *relayer* for the bottom-up messaging. A relayer is a binary that is run locally by one or more validators. It connects

* to the local Fendermint node of the validator, so as to obtain any finalized checkpoints,
* to the parent network (in case of bitcoin, to the RPC exposed by the `provider` we started in the previous guides), so as to submit the finalized checkpoint messages.

The fees for submitting the checkpoints to bitcoin are paid by the multisig that controls the subnet.

By default, the relayer binary checks for checkpoints every 15 seconds. This parameter (which is different than the checkpoint generation period that we set during subnet creation) can be changed using the `--checkpoint_interval_sec` option of the relayer binary.

Multiple relayers can be run for an L2 subnet. A validator and any other party can be a relayer. If multiple relayers are running, only one of them will successfully submit it (as we rely on Bitcoin UTXOs to this end)
{% endhint %}


---

# 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://bitcoin-scaling-labs-docs.gitbook.io/ipc-btc-scaling-docs/user-guide-for-using-subnets/subnet-creation-and-deployment.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.