Closed cwgoes closed 7 months ago
I haven't look at IBC a lot lately, but I think we it should be douable.
We have two PGF payments now:
PGFAction::Continuous
PGFAction::Retro
In PGFAction::Continuous
, PGFTarget
that has the target address and the amount is stored in the storage. Then the actual payments are executed according to PGFTarget
s every epoch in apply_inflation()
.
In PGFAction::Retro
, the payment is executed immediately.
To execute these payments over IBC, changes are required to add an IBC transfer in addition to the existing transfer.
Specifically, when the target address doesn't exist on this chain, it makes an IBC transfer message (MsgTransfer
) and execute IbcAction::execute()
with the message.
The IBC message requires:
The timeout height and timestamp can be set some long time. The addresses are the same as those of an internal transfer. The port ID and channel ID should be specified for a port/channel that are already open and on which packets are relayed by a relayer.
For the port ID and channel ID, we could add members to PGFTarget
and other structs. In this case, a proposal should include the port ID and the channel ID.
pub struct PGFTarget {
/// The target address
pub target: Address,
/// The port ID to fund over IBC
pub port_id: Option<PortId>,
/// The channel ID to fund over IBC
pub channel_id: Option<ChannelId>,
/// The amount of token to fund the target address
pub amount: Amount,
}
This broadly makes sense to me. We don't care about handling timeouts on PGF-over-IBC packets for now, the timeout parameters can just be set far in the future as you mention. One slight tweak: rather than having optional port ID and channel ID members, we should have the target
be either simply an internal address or an "IBC address" which must have the remote chain address, port ID, and channel ID.
agree with @cwgoes, 2 different targets
would be better imo
Namada should support CPGF (recurring) and RPGF (one-time) allocations which are sent to an address over IBC (maybe also over the Ethereum bridge, but we can start with only IBC). When these allocations are processed, instead of sending tokens to a Namada address (as we do for CPGF right now), we should generate an ICS20 transfer packet on the specified port, connection, and channel, to the specified destination address on the other chain. We don't need to worry about handling timeouts for now (but we should set a long timeout on the packet, maybe slightly under an epoch length).
@Fraccaman Does this seem straightforward to implement, or is anything potentially tricky?