Now that your Lightning node is up and running, the next step is to define your trader profile. This is an important choice, as it determines your channel opening strategy, the type of peers you prefer, and the way you manage liquidity.

On Lightning, for this to work, you need liquidity in the right direction. outbound liquidity corresponds to your ability to pay (sats available on your side of the channels). inbound liquidity corresponds to your capacity to receive (sats available on your peers' side). In other words, your profile boils down to a simple question: most of the time, are your sats leaving your node, or entering it?

This is the profile of the vast majority of users. You use your node to make Lightning payments: to buy goods and services, pay bills, send tips - in short, to use Lightning as a fast means of payment. On the other hand, you receive little from Lightning, or only marginally, for example a few donations, refunds between friends or a few micro-payments.

This profile is the easiest to manage, because your main need is to be able to pay. In practical terms, this means you need outbound liquidity. Once you've opened one or more correctly sized channels to stable, well-connected nodes, your outgoing payments will mechanically move liquidity to the other side of your channels. It's precisely this movement that naturally creates a reasonable amount of inbound liquidity. As a result, even if you're not looking to receive on a regular basis, you'll still be able to receive from time to time without implementing a complex strategy. So you don't need to worry about your inbound liquidity.

In this LNP202 course, we're going to focus on this "consumer" node operator profile, as it's the one that corresponds to almost all Bitcoin users on Lightning.

The merchant is, in a way, the opposite of the consumer. Here, the main objective is not to pay, but to collect. A business, service provider, online store or point of sale that accepts Lightning will receive many incoming payments, and make relatively few outgoing payments from this node.

This profile is more demanding, as a refused payment on Lightning potentially represents a lost sale. The priority therefore becomes inbound liquidity. If your node doesn't have enough inbound, your customers will see their payments fail, even if they have the funds, simply because there's no route to get the liquidity to you in the right direction.

The major challenge for the merchant also comes from the natural evolution of channels. If all you do is receive, your channels will gradually fill up on your side. So you need mechanisms to maintain and renew your inbound liquidity.

There is, however, a simpler case: the mixed consumer/merchant profile. If you collect on Lightning, but also spend on Lightning (business expenses, payments to suppliers, or even personal expenses), then your outgoing payments naturally recreate inbound. Management becomes smoother, as the flows offset each other, and you have less need to resort to artificial mechanisms designed solely to regain inbound liquidity.

The router is a specific profile. It doesn't use its Lightning node to pay or collect, but to route other people's payments and collect fees. The objective is to be a useful, reliable and economically competitive route within the Lightning graph.

To be honest with you, being a router on Lightning is a more complex business than it looks, and profitability is hard to achieve. First of all, opening and closing channels is expensive in onchain costs. To route efficiently, you often have to adjust your topology, test, close underperforming channels, open new ones, and regularly rebalance your liquidity. Secondly, competition is fierce: large, established nodes naturally capture a large share of traffic, and it's difficult to gain a foothold without tying up significant capital in well-sized channels.

There's also a high operational requirement. A routing node must be extremely stable, monitored, properly backed up, and rigorously managed. You have to monitor channel performance, adapt your fee policy, maintain balanced liquidity, manage peers, and quickly resolve technical problems. This level of involvement can be interesting as a technical hobby or as a contribution to the infrastructure, but if your goal is simply to use Lightning in a sovereign way, getting into routing to make money is rarely relevant. That's why this LNP202 course doesn't cover this profile in depth.

If you fit the consumer profile, your priority will be to be able to pay reliably with simple management. If you're a merchant, your priority will be to cash without failure, which implies an inbound liquidity acquisition strategy. If you're considering routing, you need to approach it as a demanding, economically uncertain and time-consuming activity.

Defining this profile now will help you avoid a classic pitfall: applying a channel strategy designed for a merchant or router, when you're simply a user who wants to pay.