user story: AutoStake

[turadg]

What is the Problem Being Solved?

e2e demonstration of user value of the Account interface in the Orchestration API

#8863 provides that but has more dependencies. This story is an earlier milestone.

Description of the Design

1. User invokes offer to have StakeAtom contract create a localchain account
   • Then user has a localchain Cosmos account
2. User IBC transfers ATOM (IBC Hub-Agoric) into their Agoric localchain account
   • StakeAtom-held localchain account receives assets
   • Memo field indicates invoking StakeAtom hook
   • ^ depends on the vtransfer PR
3. StakeAtom creates ICA on Cosmos Hub
4. StakeAtom triggers IBC send of ATOM to Cosmos Hub ICA
   • MsgTransfer with a memo indicating the Contract for acknowledgement
   • Localchain’s MsgTransfer sends via the transfer App
5. StakeAtom receives ack it has completed
6. StakeAtom triggers delegation to a Cosmos Hub validator

Tasks

Beta Give feedback

1. substory: user can delegate to a Cosmos Hub validator using funds in an ICA
2. substory: user can trigger staking by sending to a localchain account created with StakeAtom (depends on vtransfer hook)

• not in scope: substory: user with ATOM in LCA can send it to a new Cosmos Hub ICA

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

[dckc]

e2e demonstration of user value of Orchestration API

does that mean getChain and such? async flow?

today we (@rowgraus , @turadg , @0xpatrickdev , etc.) agreed that demonstrating only the Account API suffices here.

[0xpatrickdev]

Memo field indicates invoking StakeAtom hook

Regarding this requirement, it's not implemented in the current revision of #9666. The current logic is to stake any stakeDenom (e.g. ATOM) tokens that come to the LCA address.

It would be trivial to add logic for this, but we are blocked on testing this in an E2E until #9200 - we don't have the ability to add memos to MsgTransfer with the current stargate client.

There is other logic present in the current revision that verifies many other parts of the packet -

1. source channel matches the one we are expecting (e.g. channel-1)

2. denom matches what we are expected (viewed from the perspective of the sender, not the receiver - e.g., uatom)

3. the transfer is incoming, not outgoing (FungibleTokenPacketData.receiver)

agoric-sdk/packages/orchestration/src/examples/auto-stake-it-tap-kit.js

Lines 79 to 100 in 36f2cf6

	receiveUpcall(event) {
	trace('receiveUpcall', event);
	// ignore packets from unknown channels
	if (event.packet.source_channel !== this.state.sourceChannel) {
	return;
	}
	const tx = /** @type {FungibleTokenPacketData} */ (
	JSON.parse(atob(event.packet.data))
	);
	trace('receiveUpcall packet data', tx);
	const { remoteDenom, localChainAddress } = this.state;
	// ignore outgoing transfers
	if (tx.receiver !== localChainAddress.value) {
	return;
	}
	// only interested in transfers of `remoteDenom`
	if (tx.denom !== remoteDenom) {
	return;
	}

Edit: I would consider what's currently there enough to close the ticket, but would be happy to keep this open until 1) #9200 is completed, and 2) memo logic is added.

[turadg]

Memo field routing deferred to #9877

[aj-agoric]

Closing as this was decided to be complete with moving functionality for memo field #9877