Yep.

Depending on the size of that channel, your 29k inbound might be reserved for the penalty tx and is unusable.

Yes.

Actually, SN is estimating that trying to route you 21 sats with a maximum 3% fee, from SN's node, is not possible. You should see small zaps fail in this way more commonly than large zaps.

(If that 29k inbound is usable, our estimation might not be returning the lower bound wrt routing fees and this is a bug.)

Understanding how zaps on SN work might help some. They work like lnproxy does. We request an invoice from your node, then "wrap it" in an invoice to our node, then serve that to the sender. The sender pays that invoice by pushing bitcoin in its channels to SN, bitcoin that SN cannot claim that without paying your invoice first. SN then pays your invoice which allows us to claim the bitcoin the sender pushed to us.

So, for a zap to work the sender needs a route to SN with enough liquidity and the receiver needs a route from SN with enough liquidity.

It's built this way so that SN can take its sybil fee, verify that a payment actually happened, and that money actually changed hands. Importantly, SN cannot be paid unless you are paid first, and SN never has custody of the sender's money promising to give it to you. SN is doing exactly what a lightning routing node does wrt custody but in the application layer so we can couple the routed bitcoin to posts and comments. Also, by wrapping the invoice, the sender doesn't know the receiving node's pubkey - the sender only sees SN's pubkey - so we are fixing a lightning privacy issue in the process. confetti

Back to the error message. Before SN requests an invoice from your node for 21 sats (which is 70% of the 30 sat zap), we estimate if we can send you 21 sats with a maximum fee of 3% of zap amount (900 millisats). We estimate that it'll cost 1043 millisats to route you 21 sats, so we have the sender give you CCs instead of paying your node.