How many transactions will be created in a Lightning Network channel In a typical Lightning Network channel, how many Bitcoin transactions will be created per state of the channel that may end up on-chain ?
The number of transaction per Lightning Network channel may change depending on two main
factors:

The type of channel used.
As a protocol in development, the Lightning Network specifications may change. This
includes the specification of the transactions used for each channel state. For instance,
the &quot;Anchor Outputs&quot; proposal which was merged in 2020 included a complete rewrite of the
transaction tree.
The number of payments being currently routed through the channel (HTLCs in flight).

The following description is for a non-&quot;anchor outputs&quot; channel.
Without any in-flight HTLC
The channel begins with:

The funding transaction (onchain)
Two commitment transactions (one for each participant)

So we are at 3 transactions. But there is a quirk (there is always a quirk!), each of
the transaction pays to:

The remote party
The local party after a delay OR the remote party with the revocation key.

Since i want the count to showcase the complexity of the client implementation, i'm going
to include the special transactions in the counter.
Note that the specifications call the &quot;simple outputs&quot; (basic P2WPKH, as an onchain
payment) as being resolved, and the &quot;contract outputs&quot;[*] to not be resolved until a
&quot;special transaction&quot; spending it is confirmed.
It therefore brings us to 7 transactions:

1 revocation transaction per party
1 delayed transaction per party

Now, let's add some real complexity.
Adding the HTLCs
Lightning Network channels are bi-directional, therefore both parties can offer or
receive an HTLC. Intuitively.. HTLCs are translated into outputs than can be in both
these states (offered or received) in both the commitment transactions.
So you can have:

An HTLC offered by the local party
An HTLC received by the local party
An HTLC offered by the remote party
An HTLC received by the remote party

As well as any combination of the above.
For an HTLC offered by the local party, an &quot;offered-htlc&quot; output is added to the local
party's commitment transaction and a &quot;received-htlc&quot; output is added to the remote party's
commitment transaction.
Each of these outputs are the first stage of the onchain HTLC resolution, they are later
finalized in a second-stage pre-signed &quot;HTLC transaction&quot;, and finally sweeped by a
&quot;special transaction&quot; (the same kind as those in the first section: delayed or revocation).
An offered HTLC output in the local party's commitment transaction may be spent by:

A &quot;preimage transaction&quot; (to the remote party -- ie &quot;successful-but-quite-long payment&quot;)
A revocation transaction (to the remote party -- you need to prevent cheating at each step of the process)
A pre-signed &quot;timeout transaction&quot; which may then be spent by either:

A delayed transaction (to the local party -- ie &quot;cancelled payment&quot;)
A revocation transaction (to the remote party -- we can still cheat at this point!)



A received HTLC output in the local party's commitment transaction may be spent by:

A timeout transaction (to the local party -- that's the cltv_delta configuration on your node)
A revocation transaction (to the remote party -- as usual)
A pre-signed &quot;success transaction&quot;, which may then be spent by either:

A delayed transaction (to the local party -- ie &quot;successful-but-quite-long payment&quot;)
A revocation transaction (to the remote party, -- still to decincentivize cheating)



This brings us to 10 new transactions per commitment transaction for two HTLCs in flight
(one in both direction).
Summing it up
For the example i've showcased above it brings us to:
7 # Nuked channel
+ 10 # htlc offered on one side, received on the other one
+ 10 # htlc received on one side, offered on the other one
= 27

That's for one channel state (the next one will use new keys!) for the common scenario of
being currently forwarding a payment in both directions.
To answer your question precisely, the number of transactions per state may vary between
7 (no HTLC) and 7 + 483 * 5 * 2 = 4837 (maximum number of HTLCs in both directions).
Note that the latter is unrealistic as the maximum number of in-flight HTLCs is currently
bounded on implementations in order to avoid DOS.

More resources:

The BOLTs if you want all the nitty-gritty details:
#5
(onchain) and
#3
(transactions) cover this.
This post by Rusty Russell -- outdated but still
gives the intuition. Touchs also the challenge of managing the keys.


[*] Terminology mine on this one