Liquidity Management

voltage enterprise liquidity management the voltage enterprise plan includes full liquidity management in the context of the bitcoin lightning network, this simply means that you can rest assured knowing that payments both to and from your service will process successfully as outlined in this documentation, the primary api integrations needed for implementation do not involve managing the node's liquidity directly managing liquidity on lightning is often said to be the most time consuming aspect of using lightning, which is why the experts at voltage for over half a decade, have optimized liquidity strategies out of the box basic explainer the voltage lightning node is connected to the most in demand destinations on the lightning network these include exchanges such as binance and bitfinex, wallets, merchants, and other services after the preliminary implementation testing is complete, a production lightning node will be deployed and provisioned with liquidity from the voltage lightning node to give your users immediate connectivity to all of these destinations and more on the lightning network your team will determine the starting allocation of bitcoin for sending from the node you can access an on chain address through the lnd api or you can ask us for the on chain address to your node wallet once funds are sent to that on chain bitcoin address, the funds will be deployed into the lightning network by the liquidity team at voltage once that is complete, voltage will continue to monitor all liquidity activity and deploy more if needed, or advise your team if more outbound is needed, depending on your node's activity there is no one size fits all, which is why we remain committed to the highest standard of communication and expediency possible limitations when you are sending from your service to an outside invoice, it is possible that a payment may come back as failed this usually only happens when the invoice is being sent from a node that has poor connectivity/liquidity, or the amount is just too large to route through the network successfully the voltage node is optimized to reach nearly 99% of the network, but if numerous hops are required (meaning other nodes are forwarding the payments) the chance of success decreases due to liquidity restraints this is why we maintain direct channels to the most in demand nodes if a failure does occur you can let us know along with the invoice of the client, and we can attempt to bridge the gap and get a channel with them alternatively you can advise the user that the size is too large or to use an on chain method instead for receiving, a failed payment cannot be automatically detected when your service generates an invoice it will simply have an unpaid status even if a user attempted to pay it and it failed if a user reports that they tried to send a payment to your service and it failed, it is important to ascertain the source public key of their sending method for us to troubleshoot these limitations should be very rare but you can set limits if you choose or use a unified qr code standard such as bip21 prescribed strategy the following is the prescribed strategy to make things as simple as possible at launch if the prescribed strategy does not work with you specific usecase, then that is totally fine we can work with you on any unique considerations you may have before production node is deployed let the votlage node team khow much initial receive capacity is needed for the first 30 days as a starting point if none is provided we will start with 5,000,000 satoshis and allocate more if volume is higher than expected send on chain funds to the on chain address to be deployed as spending capacity we recommend determining what your 30 day send capacity would be as a starting point after production node is deployed once these two considerations are determined, the node will be deployed and the channel amount for inbound will be opened after the on chain amount is sent, that too will be deployed as outbound from there, voltage will monitor activity and allocate more liquidity if needed if more outbound is needed, you will be contacted via slack channel or other service excess funds if your service is primarily receiving, then it is important to remove capital from the node at regular intervals you may provide voltage with an on chain address and will send any excess funds to it or you may manage it yourself via api this is something we can determine and configure based on your specific needs if your service is primarily sending, then it is important to replenish at regular intervals this can be done in coordination with us for example if you say "if our lightning channels go below 50,000,000 sats, alert us with on chain address and we will send more funds " conclusion the voltage enterprise plan is designed to take the complexity out of lightning liquidity management so your team can focus on building great products, not maintaining channels with proactive monitoring, custom provisioning, and direct access to the most reliable peers on the network, your node will always be ready to send and receive payments with minimal friction we recognize that no two businesses are the same, which is why our team remains available to fine tune liquidity strategy, deployment thresholds, and automation triggers to suit your specific goals if you ever encounter issues, or anticipate large shifts in usage, just reach out—we’re here to make sure your lightning integration continues to perform at the highest level with voltage managing the behind the scenes complexity, you're free to deliver a seamless lightning experience to your users—fast, reliable, and globally connected from day one