Primary Channel vs Parallel Channel

In PhotonBolt, these two channel types are related, but they are not the same job. The primary channel is the first channel that makes a newly issued RGB asset usable over Lightning. A parallel channel is an additional channel added later to improve reach, scale, capacity, or routing.

1. Simple Difference

Primary Channel

The first Lightning path created for a newly issued RGB asset.

Created during or after issuance bootstrap
Uses reserved issuer liquidity
Answers: Can this asset transact over Lightning at all?
Usually tied to admin/backend infrastructure today

Parallel Channel

An extra channel created after the first working path already exists.

Created later for scale or routing
Expands asset reach or capacity
Answers: Can this asset route more volume or more peers?
Not the first prerequisite for Lightning viability

2. Visual Flow

User Issues Asset
      |
      v
Asset exists in wallet + registry
      |
      |  no primary channel yet
      v
Registry-only asset
      |
      | create first Lightning path
      v
Primary Channel Created
      |
      | asset is now Lightning-viable
      v
Users can start Lightning transfers
      |
      | add more reach / capacity / peers
      v
Parallel Channels Created
      |
      v
Better routing, more liquidity, more scale

3. Why The Primary Channel Matters More First

A token can be issued successfully and still be not ready for Lightning. That happens when the asset is visible in the wallet and in the Asset Registry, but there is no first usable channel for it yet.

That is why the primary channel is special. It is the step that changes the asset from:

Registry-only → the asset exists but is not yet Lightning-usable
Lightning-ready → the first working Lightning route exists

4. Why Parallel Channels Exist

Parallel channels are not the first unlock step. They are the growth step.

Add more liquidity after the first channel already works
Connect to more nodes or more routing peers
Reduce dependence on one path
Support more transfer volume or larger transaction demand

So if the primary channel is the first bridge, parallel channels are the extra bridges.

5. PhotonBolt Operational Reality Today

In the current PhotonBolt architecture, the wallet can request primary-channel bootstrap during issuance, but the actual execution still depends on backend/admin infrastructure.

User chooses bootstrap options in the wallet
Backend stores the liquidity plan and channel funding request
Backend creates a channel application for the new asset
BTC funding, node health, and actual channel-open work still happen on admin-controlled infrastructure
If automatic bootstrap does not finish, operator/admin action may still be required

So today the primary channel is user-requested but backend/admin-executed.

6. Comparison Table

Question	Primary Channel	Parallel Channel
When is it created?	During or just after issuance bootstrap	After the asset already has a working first channel
Why is it created?	To make the asset Lightning-usable for the first time	To improve liquidity, routing, capacity, and reach
Can the asset work without it?	No, not over Lightning	Yes, but with less scale/flexibility
Who executes it today?	Backend/admin infrastructure	Usually backend/admin infrastructure too, but as an expansion step
Main product status transition	`registry-only` → `lightning-ready`	`lightning-ready` → broader liquidity/routing coverage

7. Recommended Product Wording

To avoid confusion in the UI and docs, PhotonBolt should describe them like this:

Primary Channel: “Create the first Lightning path for this asset”
Parallel Channel: “Add another Lightning path to expand liquidity and routing”

That wording makes it clear that the primary channel is the first viability step and the parallel channel is a later scaling step.