The RPC module provides a set of APIs for developers to interact with FNN. Please note that APIs are not stable yet and may change in the future.
Allowing arbitrary machines to access the JSON-RPC port (using the rpc.listening_addr configuration option) is dangerous and strongly discouraged. Please strictly limit the access to only trusted machines.
You may refer to the e2e test cases in the tests/bruno/e2e directory for examples of how to use the RPC.
We are in a actively developing stage, don't hesitate to report issues or ask for help in the channel of the Nervos dev community.
-
- Type
Attribute - Type
CchInvoice - Type
CchOrderStatus - Type
Channel - Type
ChannelInfo - Type
ChannelState - Type
ChannelUpdateInfo - Type
CkbInvoice - Type
CkbInvoiceStatus - Type
Currency - Type
Hash256 - Type
HashAlgorithm - Type
HopHint - Type
HopRequire - Type
Htlc - Type
InvoiceData - Type
InvoiceSignature - Type
NodeInfo - Type
PaymentCustomRecords - Type
PaymentStatus - Type
PeerInfo - Type
Privkey - Type
Pubkey - Type
RemoveTlcReason - Type
RevocationData - Type
RouterHop - Type
SessionRoute - Type
SessionRouteNode - Type
SettlementData - Type
SettlementTlc - Type
TLCId - Type
TlcStatus - Type
UdtArgInfo - Type
UdtCellDep - Type
UdtCfgInfos - Type
UdtDep - Type
UdtScript
- Type
RPC module for cross chain hub demonstration.
Creates a CCH order for a BTC Lightning payee.
btc_pay_req-String, Payment request string for the BTC Lightning payee.
The invoice should not be expired soon. The remaining expiry time should be greater than the CCH config
min_incoming_invoice_expiry_delta_seconds.
currency- Currency, Request currency
timestamp-u64, Seconds since epoch when the order is createdexpiry_delta_seconds-u64, Relative expiry time in seconds fromcreated_atthat the order expireswrapped_btc_type_script-ckb_jsonrpc_types::Script, Wrapped BTC type scriptincoming_invoice- CchInvoice, Generated invoice for the incoming paymentoutgoing_pay_req-String, The final payee to accept the payment. It has the different network with incoming invoice.payment_hash- Hash256, Payment hash for the HTLC for both CKB and BTC.amount_sats-u128, Amount required to pay in Satoshis, including feefee_sats-u128, Fee in Satoshisstatus- CchOrderStatus, Order status
Creates a CCH order for a CKB Fiber payee.
fiber_pay_req-String, Payment request string for the CKB Fiber payee.
The invoice should not be expired soon. The remaining expiry time should be greater than the CCH config
min_incoming_invoice_expiry_delta_seconds.
timestamp-u64, Seconds since epoch when the order is createdexpiry_delta_seconds-u64, Relative expiry time in seconds fromcreated_atthat the order expireswrapped_btc_type_script-ckb_jsonrpc_types::Script, Wrapped BTC type scriptincoming_invoice- CchInvoice, Generated invoice for the incoming paymentoutgoing_pay_req-String, The final payee to accept the payment. It has the different network with incoming invoice.payment_hash- Hash256, Payment hash for the HTLC for both CKB and BTC.amount_sats-u128, Amount required to pay in Satoshis, including feefee_sats-u128, Fee in Satoshisstatus- CchOrderStatus, Order status
Get a CCH order by payment hash.
payment_hash- Hash256, Payment hash for the HTLC for both CKB and BTC.
timestamp-u64, Seconds since epoch when the order is createdexpiry_delta_seconds-u64, Relative expiry time in seconds fromcreated_atthat the order expireswrapped_btc_type_script-ckb_jsonrpc_types::Script, Wrapped BTC type scriptincoming_invoice- CchInvoice, Generated invoice for the incoming paymentoutgoing_pay_req-String, The final payee to accept the payment. It has the different network with incoming invoice.payment_hash- Hash256, Payment hash for the HTLC for both CKB and BTC.amount_sats-u128, Amount required to pay in Satoshis, including feefee_sats-u128, Fee in Satoshisstatus- CchOrderStatus, Order status
RPC module for channel management.
Attempts to open a channel with a peer.
peer_id-PeerId, The peer ID to open a channel with (base58 string, derived from the peer'sPubkey). The peer must be connected through the connect_peer rpc first. You can obtain a peer'speer_idfrom thelist_peersRPC.funding_amount-u128, The amount of CKB or UDT to fund the channel with.public-Option<bool>, Whether this is a public channel (will be broadcasted to network, and can be used to forward TLCs), an optional parameter, default value is true.one_way-Option<bool>, Whether this is a one-way channel (will not be broadcasted to network, and can only be used to send payment one way), an optional parameter, default value is false.funding_udt_type_script-Option<Script>, The type script of the UDT to fund the channel with, an optional parameter.shutdown_script-Option<Script>, The script used to receive the channel balance, an optional parameter, default value is the secp256k1_blake160_sighash_all script corresponding to the configured private key.commitment_delay_epoch-Option<EpochNumberWithFraction>, The delay time for the commitment transaction, must be an EpochNumberWithFraction in u64 format, an optional parameter, default value is 1 epoch, which is 4 hours.commitment_fee_rate-Option<u64>, The fee rate for the commitment transaction, an optional parameter.funding_fee_rate-Option<u64>, The fee rate for the funding transaction, an optional parameter.tlc_expiry_delta-Option<u64>, The expiry delta to forward a tlc, in milliseconds, default to 4 hours, which is 4 * 60 * 60 * 1000 milliseconds Expect it >= 2/3 commitment_delay_epoch. This parameter can be updated with rpcupdate_channellater.tlc_min_value-Option<u128>, The minimum value for a TLC our side can send, an optional parameter, default is 0, which means we can send any TLC is larger than 0. This parameter can be updated with rpcupdate_channellater.tlc_fee_proportional_millionths-Option<u128>, The fee proportional millionths for a TLC, proportional to the amount of the forwarded tlc. The unit is millionths of the amount. default is 1000 which means 0.1%. This parameter can be updated with rpcupdate_channellater. Not that, we use outbound channel to calculate the fee for TLC forwarding. For example, if we have a path A -> B -> C, then the fee B requires for TLC forwarding, is calculated the channel configuration of B and C, not A and B.max_tlc_value_in_flight-Option<u128>, The maximum value in flight for TLCs, an optional parameter. This parameter can not be updated after channel is opened.max_tlc_number_in_flight-Option<u64>, The maximum number of TLCs that can be accepted, an optional parameter, default is 125 This parameter can not be updated after channel is opened.
temporary_channel_id- Hash256, The temporary channel ID of the channel being opened
Accepts a channel opening request from a peer.
temporary_channel_id- Hash256, The temporary channel ID of the channel to acceptfunding_amount-u128, The amount of CKB or UDT to fund the channel withshutdown_script-Option<Script>, The script used to receive the channel balance, an optional parameter, default value is the secp256k1_blake160_sighash_all script corresponding to the configured private keymax_tlc_value_in_flight-Option<u128>, The max tlc sum value in flight for the channel, default is u128::MAX This parameter can not be updated after channel is opened.max_tlc_number_in_flight-Option<u64>, The max tlc number in flight send from our side, default is 125 This parameter can not be updated after channel is opened.tlc_min_value-Option<u128>, The minimum value for a TLC our side can send, an optional parameter, default is 0, which means we can send any TLC is larger than 0. This parameter can be updated with rpcupdate_channellater.tlc_fee_proportional_millionths-Option<u128>, The fee proportional millionths for a TLC, proportional to the amount of the forwarded tlc. The unit is millionths of the amount. default is 1000 which means 0.1%. This parameter can be updated with rpcupdate_channellater. Not that, we use outbound channel to calculate the fee for TLC forwarding. For example, if we have a path A -> B -> C, then the fee B requires for TLC forwarding, is calculated the channel configuration of B and C, not A and B.tlc_expiry_delta-Option<u64>, The expiry delta to forward a tlc, in milliseconds, default to 1 day, which is 24 * 60 * 60 * 1000 milliseconds This parameter can be updated with rpcupdate_channellater.
channel_id- Hash256, The final ID of the channel that was accepted, it's different from the temporary channel ID
Abandon a channel, this will remove the channel from the channel manager and DB. Only channels not in Ready or Closed state can be abandoned.
channel_id- Hash256, The temporary channel ID or real channel ID of the channel being abandoned
- None
Lists all channels.
peer_id-Option<PeerId>, The peer ID to list channels for (base58 string, derived from the peer'sPubkey). An optional parameter, if not provided, all channels will be listed.include_closed-Option<bool>, Whether to include closed channels in the list, an optional parameter, default value is falseonly_pending-Option<bool>, When set to true, only return channels that are still being opened (non-final states: negotiating, collaborating on funding tx, signing, awaiting tx signatures, awaiting channel ready) as well as channels whose opening attempt failed. Default is false. Mutually exclusive withinclude_closed.
channels- Vec<Channel>, The list of channels
Shuts down a channel.
channel_id- Hash256, The channel ID of the channel to shut downclose_script-Option<Script>, The script used to receive the channel balance, only support secp256k1_blake160_sighash_all script for now default isdefault_funding_lock_scriptinCkbConfigfee_rate-Option<u64>, The fee rate for the closing transaction, the fee will be deducted from the closing initiator's channel balance default is 1000 shannons/KWforce-Option<bool>, Whether to force the channel to close, when set to false,close_scriptandfee_rateshould be set, default is false. When set to true,close_scriptandfee_ratewill be ignored and will use the default value when opening the channel.
- None
Updates a channel.
channel_id- Hash256, The channel ID of the channel to updateenabled-Option<bool>, Whether the channel is enabledtlc_expiry_delta-Option<u64>, The expiry delta for the TLC locktimetlc_minimum_value-Option<u128>, The minimum value for a TLCtlc_fee_proportional_millionths-Option<u128>, The fee proportional millionths for a TLC
- None
RPC module for development purposes, this module is not intended to be used in production. This module will be disabled in release build.
Sends a commitment_signed message to the peer.
channel_id- Hash256, The channel ID of the channel to send the commitment_signed message to
- None
Adds a TLC to a channel.
channel_id- Hash256, The channel ID of the channel to add the TLC toamount-u128, The amount of the TLCpayment_hash- Hash256, The payment hash of the TLCexpiry-u64, The expiry of the TLChash_algorithm- Option<HashAlgorithm>, The hash algorithm of the TLC
tlc_id-u64, The ID of the TLC
Removes a TLC from a channel.
channel_id- Hash256, The channel ID of the channel to remove the TLC fromtlc_id-u64, The ID of the TLC to removereason- RemoveTlcReason, The reason for removing the TLC, either a 32-byte hash for preimage fulfillment or an u32 error code for removal
- None
Submit a commitment transaction to the chain
channel_id- Hash256, Channel IDcommitment_number-u64, Commitment number
tx_hash- Hash256, Submitted commitment transaction hash
Manually trigger CheckShutdownTx on all channels
channel_id- Hash256, Channel ID
- None
RPC module for graph management.
Get the list of nodes in the network graph.
limit-Option<u64>, The maximum number of nodes to return.after-Option<JsonBytes>, The cursor to start returning nodes from.
nodes- Vec<NodeInfo>, The list of nodes.last_cursor-JsonBytes, The last cursor.
Get the list of channels in the network graph.
limit-Option<u64>, The maximum number of channels to return.after-Option<JsonBytes>, The cursor to start returning channels from.
channels- Vec<ChannelInfo>, A list of channels.last_cursor-JsonBytes, The last cursor for pagination.
The RPC module for node information.
Get the node information.
- None
version-String, The version of the node software.commit_hash-String, The commit hash of the node software.node_id- Pubkey, The identity public key of this node (secp256k1 compressed, hex string). This is the same value referred to aspubkeyinlist_peersresponses. Note: this is different frompeer_id, which is a base58 hash derived from this key.features-Vec<String>, The features supported by the node.node_name-Option<String>, The optional name of the node.addresses-Vec<MultiAddr>, A list of multi-addresses associated with the node.chain_hash- Hash256, The hash of the blockchain that the node is connected to.open_channel_auto_accept_min_ckb_funding_amount-u64, The minimum CKB funding amount for automatically accepting open channel requests, serialized as a hexadecimal string.auto_accept_channel_ckb_funding_amount-u64, The CKB funding amount for automatically accepting channel requests, serialized as a hexadecimal string.default_funding_lock_script-Script, The default funding lock script for the node.tlc_expiry_delta-u64, The locktime expiry delta for Time-Locked Contracts (TLC), serialized as a hexadecimal string.tlc_min_value-u128, The minimum value for Time-Locked Contracts (TLC) we can send, serialized as a hexadecimal string.tlc_fee_proportional_millionths-u128, The fee (to forward payments) proportional to the value of Time-Locked Contracts (TLC), expressed in millionths and serialized as a hexadecimal string.channel_count-u32, The number of channels associated with the node, serialized as a hexadecimal string.pending_channel_count-u32, The number of pending channels associated with the node, serialized as a hexadecimal string.peers_count-u32, The number of peers connected to the node, serialized as a hexadecimal string.udt_cfg_infos- UdtCfgInfos, Configuration information for User-Defined Tokens (UDT) associated with the node.
RPC module for invoice management.
Generates a new invoice.
amount-u128, The amount of the invoice.description-Option<String>, The description of the invoice.currency- Currency, The currency of the invoice.payment_preimage- Option<Hash256>, The preimage to settle an incoming TLC payable to this invoice. If preimage is set, hash must be absent. If both preimage and hash are absent, a random preimage is generated.payment_hash- Option<Hash256>, The hash of the preimage. If hash is set, preimage must be absent. This condition indicates a 'hold invoice' for which the tlc must be accepted and held until the preimage becomes known.expiry-Option<u64>, The expiry time of the invoice, in seconds.fallback_address-Option<String>, The fallback address of the invoice.final_expiry_delta-Option<u64>, The final HTLC timeout of the invoice, in milliseconds. Minimal value is 16 hours, and maximal value is 14 days.udt_type_script-Option<Script>, The UDT type script of the invoice.hash_algorithm- Option<HashAlgorithm>, The hash algorithm of the invoice.allow_mpp-Option<bool>, Whether allow payment to use MPPallow_trampoline_routing-Option<bool>, Whether allow payment to use trampoline routing
invoice_address-String, The encoded invoice address.invoice- CkbInvoice, The invoice.
Parses a encoded invoice.
invoice-String, The encoded invoice address.
invoice- CkbInvoice, The invoice.
Retrieves an invoice.
payment_hash- Hash256, The payment hash of the invoice.
invoice_address-String, The encoded invoice address.invoice- CkbInvoice, The invoice.status- CkbInvoiceStatus, The invoice status
Cancels an invoice, only when invoice is in status Open can be canceled.
payment_hash- Hash256, The payment hash of the invoice.
invoice_address-String, The encoded invoice address.invoice- CkbInvoice, The invoice.status- CkbInvoiceStatus, The invoice status
Settles an invoice by saving the preimage to this invoice.
payment_hash- Hash256, The payment hash of the invoice.payment_preimage- Hash256, The payment preimage of the invoice.
- None
RPC module for channel management.
Sends a payment to a peer.
target_pubkey- Option<Pubkey>, The public key (Pubkey) of the payment target node, serialized as a hex string. You can obtain a node's pubkey via thenode_infoorgraph_nodesRPC. Note: this is thePubkey(secp256k1 public key), not thePeerId.amount-Option<u128>, the amount of the payment, the unit is Shannons for non UDT payment If not set and there is a invoice, the amount will be set to the invoice amountpayment_hash- Option<Hash256>, the hash to use within the payment's HTLC. If not set andkeysendis set to true, a random hash will be generated. If not set and there is apayment_hashin the invoice, it will be used. Otherwise,payment_hashneed to be set.final_tlc_expiry_delta-Option<u64>, the TLC expiry delta should be used to set the timelock for the final hop, in millisecondstlc_expiry_limit-Option<u64>, the TLC expiry limit for the whole payment, in milliseconds, each hop is with a default tlc delta of 1 day suppose the payment router is with N hops, the total tlc expiry limit is at least (N-1) days this is also the default value for the payment if this parameter is not providedinvoice-Option<String>, the encoded invoice to send to the recipienttimeout-Option<u64>, the payment timeout in seconds, if the payment is not completed within this time, it will be cancelledmax_fee_amount-Option<u128>, the maximum fee amounts in shannons that the sender is willing to pay. Note: In trampoline routing mode, the sender will use the max_fee_amount as the total fee as much as possible.max_fee_rate-Option<u64>, the maximum fee rate per thousand (‰), default is 5 (0.5%)max_parts-Option<u64>, max parts for the payment, only used for multi-part paymentstrampoline_hops- Option<Vec<Pubkey>>, Optional explicit trampoline hops.
When set to a non-empty list [t1, t2, ...], routing will only find a path from the
payer to t1, and the inner trampoline onion will encode t1 -> t2 -> ... -> final.
keysend-Option<bool>, keysend paymentudt_type_script-Option<Script>, udt type script for the paymentallow_self_payment-Option<bool>, Allow paying yourself through a circular route, default is false. This is useful for channel rebalancing: the payment flows out of one channel and back through another, shifting liquidity between your channels without changing your total balance (only routing fees are deducted). Settarget_pubkeyto your own node pubkey andkeysendtotrueto perform a rebalance. Note:allow_self_paymentis not compatible with trampoline routing.custom_records- Option<PaymentCustomRecords>, Some custom records for the payment which contains a map of u32 to Vec The key is the record type, and the value is the serialized data For example:
"custom_records": {
"0x1": "0x01020304",
"0x2": "0x05060708",
"0x3": "0x090a0b0c",
"0x4": "0x0d0e0f10010d090a0b0c"
}hop_hints- Option<Vec<HopHint>>, Optional route hints to reach the destination through private channels. Note:- this is only used for the private channels with the last hop.
hop_hintsis only ahintfor routing algorithm, it is not a guarantee that the payment will be routed through the specified channels, it is up to the routing algorithm to decide whether to use the hints or not.
For example (pubkey, channel_outpoint, fee_rate, tlc_expiry_delta) suggest path router
to use the channel of channel_outpoint at hop with pubkey to forward the payment
and the fee rate is fee_rate and tlc_expiry_delta is tlc_expiry_delta.
dry_run-Option<bool>, dry_run for payment, used for check whether we can build valid router and the fee for this payment, it's useful for the sender to double check the payment before sending it to the network, default is false
payment_hash- Hash256, The payment hash of the paymentstatus- PaymentStatus, The status of the paymentcreated_at-u64, The time the payment was created at, in milliseconds from UNIX epochlast_updated_at-u64, The time the payment was last updated at, in milliseconds from UNIX epochfailed_error-Option<String>, The error message if the payment failedfee-u128, fee paid for the paymentcustom_records- Option<PaymentCustomRecords>, The custom records to be included in the payment.routers- Vec<SessionRoute>, The router is a list of nodes that the payment will go through. We store in the payment session and then will use it to track the payment history. The router is a list of nodes that the payment will go through. If the payment adapted MPP (multi-part payment), the routers will be a list of nodes For example:A(amount, channel) -> B -> C -> Dmeans A will sendamountwithchannelto B.
Retrieves a payment.
payment_hash- Hash256, The payment hash of the payment to retrieve
payment_hash- Hash256, The payment hash of the paymentstatus- PaymentStatus, The status of the paymentcreated_at-u64, The time the payment was created at, in milliseconds from UNIX epochlast_updated_at-u64, The time the payment was last updated at, in milliseconds from UNIX epochfailed_error-Option<String>, The error message if the payment failedfee-u128, fee paid for the paymentcustom_records- Option<PaymentCustomRecords>, The custom records to be included in the payment.routers- Vec<SessionRoute>, The router is a list of nodes that the payment will go through. We store in the payment session and then will use it to track the payment history. The router is a list of nodes that the payment will go through. If the payment adapted MPP (multi-part payment), the routers will be a list of nodes For example:A(amount, channel) -> B -> C -> Dmeans A will sendamountwithchannelto B.
Builds a router with a list of pubkeys and required channels.
amount-Option<u128>, the amount of the payment, the unit is Shannons for non UDT payment If not set, the minimum routable amount1is usedudt_type_script-Option<Script>, udt type script for the payment routerhops_info- Vec<HopRequire>, A list of hops that defines the route. This does not include the source hop pubkey. A hop info is a tuple of pubkey and the channel(specified by channel funding tx) will be used. This is a strong restriction given on payment router, which means these specified hops and channels must be adapted in the router. This is different from hop hints, which maybe ignored by find path. If channel is not specified, find path algorithm will pick a channel within these two peers.
An error will be returned if there is no router could be build from given hops and channels
final_tlc_expiry_delta-Option<u64>, the TLC expiry delta should be used to set the timelock for the final hop, in milliseconds
router_hops- Vec<RouterHop>, The hops information for router
Sends a payment to a peer with specified router. This method differs from SendPayment in that it allows users to specify a full route manually.
A typical use case is channel rebalancing: you can construct a circular route (your node -> intermediate nodes -> your node) to shift liquidity between your channels.
To rebalance, follow these steps:
- Call
build_routerwithhops_infodefining the circular route you want, e.g. your_node -> peer_A -> peer_B -> your_node. - Call
send_payment_with_routerwith the returnedrouter_hopsandkeysend: true.
Only routing fees are deducted; your total balance across channels remains the same.
payment_hash- Option<Hash256>, the hash to use within the payment's HTLC. If not set andkeysendis set to true, a random hash will be generated. If not set and there is apayment_hashin the invoice, it will be used. Otherwise,payment_hashneed to be set.router- Vec<RouterHop>, The router to use for the paymentinvoice-Option<String>, the encoded invoice to send to the recipientcustom_records- Option<PaymentCustomRecords>, Some custom records for the payment which contains a map of u32 to Vec The key is the record type, and the value is the serialized data. Limits: the sum size of values can not exceed 2048 bytes.
For example:
"custom_records": {
"0x1": "0x01020304",
"0x2": "0x05060708",
"0x3": "0x090a0b0c",
"0x4": "0x0d0e0f10010d090a0b0c"
}keysend-Option<bool>, keysend paymentudt_type_script-Option<Script>, udt type script for the paymentdry_run-Option<bool>, dry_run for payment, used for check whether we can build valid router and the fee for this payment, it's useful for the sender to double check the payment before sending it to the network, default is false
payment_hash- Hash256, The payment hash of the paymentstatus- PaymentStatus, The status of the paymentcreated_at-u64, The time the payment was created at, in milliseconds from UNIX epochlast_updated_at-u64, The time the payment was last updated at, in milliseconds from UNIX epochfailed_error-Option<String>, The error message if the payment failedfee-u128, fee paid for the paymentcustom_records- Option<PaymentCustomRecords>, The custom records to be included in the payment.routers- Vec<SessionRoute>, The router is a list of nodes that the payment will go through. We store in the payment session and then will use it to track the payment history. The router is a list of nodes that the payment will go through. If the payment adapted MPP (multi-part payment), the routers will be a list of nodes For example:A(amount, channel) -> B -> C -> Dmeans A will sendamountwithchannelto B.
RPC module for peer management.
Connect to a peer.
address-MultiAddr, The address of the peer to connect to.save-Option<bool>, Whether to save the peer address to the peer store.
- None
Disconnect from a peer.
peer_id-PeerId, The peer ID of the peer to disconnect (base58 string, derived from the peer'sPubkey).
- None
List connected peers
- None
peers- Vec<PeerInfo>, A list of connected peers.
RPC module for profiling This module require build with pprof feature and debug symbol.
Collects a temporary CPU profile and writes a flamegraph SVG to disk.
duration_secs-Option<u64>, Duration to profile in seconds. Defaults 10s.
path-String, Path of the generated flamegraph SVG.
RPC module for watchtower related operations
Create a new watched channel
channel_id- Hash256, Channel IDfunding_udt_type_script-Option<Script>, Funding UDT type scriptlocal_settlement_key- Privkey, The local party's private key used to settle the commitment transactionremote_settlement_key- Pubkey, The remote party's public key used to settle the commitment transactionlocal_funding_pubkey- Pubkey, The local party's funding public keyremote_funding_pubkey- Pubkey, The remote party's funding public keysettlement_data- SettlementData, Settlement data
- None
Remove a watched channel
channel_id- Hash256, Channel ID
- None
Update revocation
channel_id- Hash256, Channel IDrevocation_data- RevocationData, Revocation datasettlement_data- SettlementData, Settlement data
- None
Update pending remote settlement
channel_id- Hash256, Channel IDsettlement_data- SettlementData, Settlement data
- None
Update settlement
channel_id- Hash256, Channel IDsettlement_data- SettlementData, Settlement data
- None
Create preimage
- None
Remove preimage
payment_hash- Hash256, Payment hash
- None
The attributes of the invoice
FinalHtlcTimeout-u64, This attribute is deprecated since v0.6.0, The final tlc time out, in millisecondsFinalHtlcMinimumExpiryDelta-u64, The final tlc minimum expiry delta, in milliseconds, default is 1 dayExpiryTime-Duration, The expiry time of the invoice, in secondsDescription-String, The description of the invoiceFallbackAddr-String, The fallback address of the invoiceUdtScript- CkbScript, The udt type script of the invoicePayeePublicKey-PublicKey, The payee public key of the invoiceHashAlgorithm- HashAlgorithm, The hash algorithm of the invoiceFeature-Vec<String>, The feature flags of the invoicePaymentSecret- Hash256, The payment secret of the invoice
The generated proxy invoice for the incoming payment.
The JSON representation:
{ "Fiber": String } | { "Lightning": String }
Fiber- CkbInvoice, Fiber invoice that once paid, the hub will send the outgoing payment to LightningLightning-Bolt11Invoice, Lightning invoice that once paid, the hub will send the outgoing payment to Fiber
The status of a cross-chain hub order, will update as the order progresses.
Pending- Order is created and waiting for the incoming invoice to collect enough TLCs.IncomingAccepted- The incoming invoice collected the required TLCs and is ready to send outgoing payment to obtain the preimage.OutgoingInFlight- The outgoing payment is in flight.OutgoingSucceeded- The outgoing payment is settled and preimage has been obtained.Succeeded- Both payments are settled and the order succeeds.Failed- Order is failed.
The channel data structure
channel_id- Hash256, The channel IDis_public-bool, Whether the channel is publicis_acceptor-bool, Is this channel initially inbound? An inbound channel is one where the counterparty is the funder of the channel.is_one_way-bool, Is this channel one-way? Combines with is_acceptor to determine if the channel able to send payment to the counterparty or not.channel_outpoint-Option<OutPoint>, The outpoint of the channelpeer_id-PeerId, The peer ID of the channel counterparty (base58 string, derived from the peer'sPubkey).funding_udt_type_script-Option<Script>, The UDT type script of the channelstate- ChannelState, The state of the channellocal_balance-u128, The local balance of the channeloffered_tlc_balance-u128, The offered balance of the channelremote_balance-u128, The remote balance of the channelreceived_tlc_balance-u128, The received balance of the channelpending_tlcs- Vec<Htlc>, The list of pending tlcslatest_commitment_transaction_hash-Option<H256>, The hash of the latest commitment transactioncreated_at-u64, The time the channel was created at, in milliseconds from UNIX epochenabled-bool, Whether the channel is enabledtlc_expiry_delta-u64, The expiry delta to forward a tlc, in milliseconds, default to 1 day, which is 24 * 60 * 60 * 1000 milliseconds This parameter can be updated with rpcupdate_channellater.tlc_fee_proportional_millionths-u128, The fee proportional millionths for a TLC, proportional to the amount of the forwarded tlc. The unit is millionths of the amount. default is 1000 which means 0.1%. This parameter can be updated with rpcupdate_channellater. Not that, we use outbound channel to calculate the fee for TLC forwarding. For example, if we have a path A -> B -> C, then the fee B requires for TLC forwarding, is calculated the channel configuration of B and C, not A and B.shutdown_transaction_hash-Option<H256>, The hash of the shutdown transactionfailure_detail-Option<String>, Human-readable reason why the channel opening failed. Only present when the channel is in a failed state (e.g. abandoned or funding aborted).
The Channel information.
channel_outpoint-OutPoint, The outpoint of the channel.node1- Pubkey, The identity public key of the first node (secp256k1 compressed, hex string).node2- Pubkey, The identity public key of the second node (secp256k1 compressed, hex string).created_timestamp-u64, The created timestamp of the channel, which is the block header timestamp of the block that contains the channel funding transaction.update_info_of_node1- Option<ChannelUpdateInfo>, The update info from node1 to node2, e.g. timestamp, fee_rate, tlc_expiry_delta, tlc_minimum_valueupdate_info_of_node2- Option<ChannelUpdateInfo>, The update info from node2 to node1, e.g. timestamp, fee_rate, tlc_expiry_delta, tlc_minimum_valuecapacity-u128, The capacity of the channel.chain_hash- Hash256, The chain hash of the channel.udt_type_script-Option<Script>, The UDT type script of the channel.
The state of a channel
NegotiatingFunding-NegotiatingFundingFlags, We are negotiating the parameters required for the channel prior to funding it.CollaboratingFundingTx-CollaboratingFundingTxFlags, We're collaborating with the other party on the funding transaction.SigningCommitment-SigningCommitmentFlags, We have collaborated over the funding and are now waiting for CommitmentSigned messages.AwaitingTxSignatures-AwaitingTxSignaturesFlags, We've received and sentcommitment_signedand are now waiting for both party to collaborate on creating a valid funding transaction.AwaitingChannelReady-AwaitingChannelReadyFlags, We've received/sentfunding_createdandfunding_signedand are thus now waiting on the funding transaction to confirm.ChannelReady- Both we and our counterparty consider the funding transaction confirmed and the channel is now operational.ShuttingDown-ShuttingDownFlags, We've successfully negotiated aclosing_signeddance. At this point, theChannelManagerClosed-CloseFlags, This channel is closed.
The channel update info with a single direction of channel
timestamp-u64, The timestamp is the time when the channel update was received by the node.enabled-bool, Whether the channel can be currently used for payments (in this one direction).outbound_liquidity-Option<u128>, The exact amount of balance that we can send to the other party via the channel.tlc_expiry_delta-u64, The difference in htlc expiry values that you must have when routing through this channel (in milliseconds).tlc_minimum_value-u128, The minimum value, which must be relayed to the next hop via the channelfee_rate-u64, The forwarding fee rate for the channel.
Represents a syntactically and semantically correct lightning BOLT11 invoice
There are three ways to construct a CkbInvoice:
- using [
CkbInvoiceBuilder] - using
str::parse::<CkbInvoice>(&str)(see [CkbInvoice::from_str])
currency- Currency, The currency of the invoiceamount-Option<u128>, The amount of the invoicesignature- Option<InvoiceSignature>, The signature of the invoicedata- InvoiceData, The invoice data, including the payment hash, timestamp and other attributes
The currency of the invoice, can also used to represent the CKB network chain.
Open- The invoice is open and can be paid.Cancelled- The invoice is cancelled.Expired- The invoice is expired.Received- The invoice is received, but not settled yet.Paid- The invoice is paid.
The currency of the invoice, can also used to represent the CKB network chain.
Fibb- The mainnet currency of CKB.Fibt- The testnet currency of the CKB network.Fibd- The devnet currency of the CKB network.
A 256-bit hash digest, used as identifier of channel, payment, transaction hash etc.
HashAlgorithm is the hash algorithm used in the hash lock.
CkbHash- The default hash algorithm, CkbHashSha256- The sha256 hash algorithm
A hop hint is a hint for a node to use a specific channel.
pubkey- Pubkey, The public key of the nodechannel_outpoint-OutPoint, The outpoint of the channelfee_rate-u64, The fee rate to use this hop to forward the payment.tlc_expiry_delta-u64, The TLC expiry delta to use this hop to forward the payment.
A hop requirement need to meet when building router, do not including the source node, the last hop is the target node.
pubkey- Pubkey, The public key of the nodechannel_outpoint-Option<OutPoint>, The outpoint for the channel, which means use channel withchannel_outpointto reach this node
The htlc data structure
id-u64, The id of the htlcamount-u128, The amount of the htlcpayment_hash- Hash256, The payment hash of the htlcexpiry-u64, The expiry of the htlcforwarding_channel_id- Option<Hash256>, If this HTLC is involved in a forwarding operation, this field indicates the forwarding channel. For an outbound htlc, it is the inbound channel. For an inbound htlc, it is the outbound channel.forwarding_tlc_id-Option<u64>, If this HTLC is involved in a forwarding operation, this field indicates the forwarding tlc id.status- TlcStatus, The status of the htlc
The metadata of the invoice
timestamp-u128, The timestamp of the invoicepayment_hash- Hash256, The payment hash of the invoiceattrs- Vec<Attribute>, The attributes of the invoice, e.g. description, expiry time, etc.
Recoverable signature
The Node information.
node_name-String, The name of the node.version-String, The version of the node.addresses-Vec<MultiAddr>, The addresses of the node.features-Vec<String>, The node features supported by the node.node_id- Pubkey, The identity public key of the node (secp256k1 compressed, hex string), same aspubkeyinlist_peers.timestamp-u64, The latest timestamp set by the owner for the node announcement. When a Node is online this timestamp will be updated to the latest value.chain_hash- Hash256, The chain hash of the node.auto_accept_min_ckb_funding_amount-u64, The minimum CKB funding amount for automatically accepting open channel requests.udt_cfg_infos- UdtCfgInfos, The UDT configuration infos of the node.
The custom records to be included in the payment.
The key is hex encoded of u32, it's range limited in 0 ~ 65535, and the value is hex encoded of Vec<u8> with 0x as prefix.
For example:
"custom_records": {
"0x1": "0x01020304",
"0x2": "0x05060708",
"0x3": "0x090a0b0c",
"0x4": "0x0d0e0f10010d090a0b0c"
}data-HashMap<u32::Vec<u8>>, The custom records to be included in the payment.
The status of a payment, will update as the payment progresses.
The transfer path for payment status is Created -> Inflight -> Success | Failed.
MPP Behavior: A single session may involve multiple attempts (HTLCs) to fulfill the total amount.
Created- Initial status. A payment session is created, but no HTLC has been dispatched.Inflight- The first hop AddTlc is sent successfully and waiting for the response.
MPP Logic: Status
Inflightmeans at least one attempt is still not inSuccess, payment needs more retrying or waiting for HTLC settlement.
Success- The payment is finished. All related HTLCs are successfully settled, and the aggregate amount equals the total requested amount.Failed- The payment session has terminated. HTLCs have failed and the target amount cannot be fulfilled after exhausting all retries.
The information about a peer connected to the node.
pubkey- Pubkey, The identity public key of the peer (also known asnode_id).peer_id-PeerId, The peer ID of the peer (base58 string, derived by hashing thepubkeyabove). This is used for P2P transport connections, e.g. when callingopen_channelordisconnect_peer.address-MultiAddr, The multi-address associated with the connecting peer. Note: this is only the address which used for connecting to the peer, not all addresses of the peer. Thegraph_nodesin Graph rpc module will return all addresses of the peer.
A wrapper for secp256k1 secret key
A compressed secp256k1 public key (33 bytes), used as the primary identity of a node.
In the RPC interface this value is also referred to as node_id.
It is serialized as a 66-character hex string (e.g. "02aaaa...") in JSON.
Note: Pubkey is different from PeerId. A PeerId is derived by hashing the
public key and is used only for P2P transport connections. You can obtain both
values from the list_peers or node_info RPC.
The reason for removing a TLC
RemoveTlcFulfill- The reason for removing the TLC is that it was fulfilledRemoveTlcFail- The reason for removing the TLC is that it failed
Data needed to revoke an outdated commitment transaction.
commitment_number-u64, The commitment transaction version number that was revokedaggregated_signature-CompactSignature, The aggregated signature from both parties that authorizes the revocationoutput-CellOutput, The output cell from the revoked commitment transactionoutput_data-Bytes, The associated data for the output cell (e.g., UDT amount for token transfers)
A router hop information for a payment, a paymenter router is an array of RouterHop,
a router hop generally implies hop target will receive amount_received with channel_outpoint of channel.
Improper hop hint may make payment fail, for example the specified channel do not have enough capacity.
target- Pubkey, The node that is sending the TLC to the next node.channel_outpoint-OutPoint, The channel of this hop used to receive TLCamount_received-u128, The amount that the source node will transfer to the target node. We have already added up all the fees along the path, so this amount can be used directly for the TLC.incoming_tlc_expiry-u64, The expiry for the TLC that the source node sends to the target node. We have already added up all the expiry deltas along the path, the only thing missing is current time. So the expiry is the current time plus the expiry delta.
The router is a list of nodes that the payment will go through.
We store in the payment session and then will use it to track the payment history.
The router is a list of nodes that the payment will go through.
For example:
A(amount, channel) -> B -> C -> D
means A will send amount with channel to B.
nodes- Vec<SessionRouteNode>, the nodes in the route
The node and channel information in a payment route hop
pubkey- Pubkey, the public key of the nodeamount-u128, the amount for this hopchannel_outpoint-OutPoint, the channel outpoint for this hop
Data needed to authorize and execute a settlement transaction.
local_amount-u128, The total amount of CKB/UDT being settled for the local partyremote_amount-u128, The total amount of CKB/UDT being settled for the remote partytlcs- Vec<SettlementTlc>, The list of pending Time-Locked Contracts (TLCs) included in this settlement
Data needed to authorize and execute a Time-Locked Contract (TLC) settlement transaction.
tlc_id- TLCId, The ID of the TLC (either offered or received)hash_algorithm- HashAlgorithm, The hash algorithm used for the TLCpayment_amount-u128, The amount of CKB/UDT involved in the TLCpayment_hash- Hash256, The hash of the payment preimageexpiry-u64, The expiry time for the TLC in millisecondslocal_key- Privkey, The local party's private key used to sign the TLCremote_key- Pubkey, The remote party's public key used to verify the TLC
The id of a tlc, it can be either offered or received.
Offered-u64, Offered tlc idReceived-u64, Received tlc id
The status of a tlc
Outbound- OutboundTlcStatus, Outbound tlcInbound- InboundTlcStatus, Inbound tlc
The UDT argument info which is used to identify the UDT configuration
name-String, The name of the UDT.script- UdtScript, The script of the UDT.auto_accept_amount-Option<u128>, The minimum amount of the UDT that can be automatically accepted.cell_deps- Vec<UdtDep>, The cell deps of the UDT.
The UDT cell dep which is used to identify the UDT configuration for a Fiber Node
out_point-OutPointWrapper, The out point of the cell dep.dep_type-DepType, The type of the cell dep.
A list of UDT configuration infos.
Udt script on-chain dependencies.
cell_dep- Option<UdtCellDep>, cell dep described by out_point.type_id-Option<Script>, cell dep described by type ID.
The UDT script which is used to identify the UDT configuration for a Fiber Node
code_hash-H256, The code hash of the script.hash_type-ScriptHashType, The hash type of the script.args-String, The arguments of the script.