cli

type Processor ¶

type Processor struct {
	// contains filtered or unexported fields
}

func (p *Processor) ConfigXnet()

func (p *Processor) ConfirmSettle()

func (p *Processor) ConfirmWithdraw()

func (p *Processor) DeleteBridgeRouting()

func (p *Processor) DeleteNetBridge()

func (p *Processor) DeleteNetToken()

func (p *Processor) DeregisterRouter()

func (p *Processor) IntendSettle()

func (p *Processor) IntendWithdraw()

func (p *Processor) NativeWrapDeposit()

func (p *Processor) NativeWrapWithdraw()

func (p *Processor) RegisterRouter()

func (p *Processor) SetBridgeRouting()

func (p *Processor) SetNetBridge()

func (p *Processor) SetNetId()

func (p *Processor) SetNetToken()

func (p *Processor) Setup(db, ospkey, disputer bool)

func (p *Processor) ViewAppOnChain()

func (p *Processor) ViewChannel()

func (p *Processor) ViewChannelOnChain()

func (p *Processor) ViewDeposit()

func (p *Processor) ViewPay()

func (p *Processor) ViewPayOnChain()

func (p *Processor) ViewRoute()

func (p *Processor) ViewTxOnChain()

func (p *Processor) ViewXnet()

func (p *Processor) ViewXnetPay()

type XnetConfig ¶

type XnetConfig struct {
	NetId         uint64                       `json:"net_id"`         // local net id
	NetBridge     map[string]uint64            `json:"net_bridge"`     // bridgeAddr -> bridgeNetId
	BridgeRouting map[uint64]string            `json:"bridge_routing"` // destNetId -> nextHopBridgeAddr
	NetToken      map[string]map[uint64]string `json:"net_token"`      // localTokenAddr -> map(remoteNetId -> remoteTokenAddr)
}

XnetConfig is the operator-supplied cross-net routing configuration.

A "net" is identified by (chainId, CelerLedger): the CelerLedger's constructor binds NativeWrap (the chain's WETH-style wrapped-native contract), PayRegistry, and CelerWallet, and the PayResolver feeding that PayRegistry (with its bound VirtResolver) is uniquely determined per deployment, so the full contract set is derivable from the ledger. Two OSPs sharing a netId must boot against the same CelerLedger address on the same chain; otherwise channels and signed messages won't validate across them.

netId is intentionally separate from `block.chainid` for two reasons:

1. A contract-set redeployment on the same chain (upgrades, hard-fork- style migrations) is a new net even though chainId is unchanged — the new PayResolver enforces `pay.payResolver == address(this)` and the new Ledger enforces `initializer.ledger_address == address(this)`, so signed messages don't cross over. A bridge pair operated by the same business entity can carry pays across the migration window without users having to coordinate the upgrade.
2. Test harnesses can simulate cross-net routing on a single geth instance by deploying multiple contract sets and labelling them as distinct nets.

On-chain replay protection lives in the contracts: chainId and ledger_address are signed into PaymentChannelInitializer; chainId is signed into ConditionalPay; payResolver is bound on every pay. netId only drives off-chain forwarding decisions.

Bridge OSPs at a net boundary are operated as a trust unit (typically by the same business entity). The cross-bridge link is a direct gRPC stream between the two bridge processes, not a payment channel — there's no shared on-chain state between bridges, and reconciliation between them is off-protocol.

func ParseXnetConfig(path string) (*XnetConfig, error)