IST & PSM Forwarder Contract

[jeetraut]

Description

Create an Agoric contract that can do the following:

1. Receive an ERTP asset over an IBC transaction and a destination Agoric address as inputs
2. Trade that ERTP asset to the Agoric Parity Stability Module (PSM) in exchange for IST (assuming the PSM accepts this ERTP asset)
3. Sends the IST received to the destination Agoric address received as an input

Context

This contract will act as connective tissue to enable easier onboarding of IST from external stablecoins that are accepted by the Agoric PSM (for example, Axelar-USDC).

Acceptance Criteria

• Functionality outlined in description is complete
• Code passes review by Agoric team
• Code is open sourced and submission includes a video walkthrough/demo

Time Estimation

2 weeks

Reward

$6,400

Payment will be made in USD (fiat currency) via wire transfer. The developer is responsible for providing their completed tax documents (W9 for US based developers and/or W8 or W8-BEN-E for non-US based developers) and providing their banking details in order to receive payment.

Applicant Assessment Criteria

Important: Please provide a clear workplan for how you will approach this bounty. Use the work plan as an initial demonstration that you would be a good candidate. Bounties will require coordination with the Agoric team, so unfortunately only plans submitted in English will be considered.

Applicants will be assessed based on the following criteria:

• Issue-specific domain experience
• Issue-specific technical capability
• Familiarity with Agoric's platform
• JavaScript experience
• Availability and communication

Experience Write-up

As part of completing the bounty, we ask that you write up a short (or long!) summary of your experience building on Agoric. This is important feedback for us as we evolve the platform.

Review Process

• Agoric team reviews your submitted workplan on Gitcoin
  • It is best to join our Discord and post your gitcoin name in the bounties channel, so that we can follow up with you. Otherwise, we will write on your gitcoin profile wall and say hello!
• Agoric contacts you to provide reference projects / sample code for engineering review
• Introductory call to discuss your plans and expected timeline
• You join the Agoric Discord bounties channel (if you haven’t done so already)
• Agoric accepts you on Gitcoin and you get started!

References

• agoric.com/documentation
• #bounties channel in Discord for general questions and your private bounty channel for direct questions to the Agoric team

Tasks

Beta Give feedback

1. can't send to account by address: namesByAddress is empty #8113
   3 of 3
   bug namehub-petname +2
   

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

Work has been started.

These users each claimed they can complete the work by 264 years, 3 months from now.
Please review their action plans below:

1) benbaessler has applied to start work (Funders only: approve worker | reject worker).

I am a developer with 3+ of software dev experience who works with Solidity & JavaScript / TypeScript on a daily basis.
Since I have extensive experience with smart contracts, I am definitely able to build this contract for you.

My work plan:

1. Read and understand any related documentations / resources
2. Visualise / note down the logic of the contract and its functions
3. Build the contract using the Agoric Zoe framework
4. Write and run extensive tests for the contract
5. Upload code to GitHub & create a demo video
   I will, of course, keep the Agoric team updated on my progress throughout the entire process.

If you want to take a look at some of my previous work, this is my portfolio website: https://benbaessler.com
By the way, I have full-time availability. :)
2) thisispalash has been approved to start work.

I am highly interested in completing this bounty and think I should be able to complete this by mid August. I have been browsing through the Agoric documentation, and this would be a good first bounty to get my hands dirty with Agoric.

The steps I foresee for this bounty —

1. Meet with the Agoric team and discuss (and finalize) approach
2. Develop!
   — Module to check if the incoming asset is accepted by PSM
   — Make the trade to IST
   — Send the IST to the destination address
3. Write unit tests (maybe along with develop, as a good practice)
4. Write integration tests
5. Write docs to explain code
6. Record a small video walkthrough
7. Submit!
8. Write out experience doc

Looking forward to meeting with the team and starting work on this bounty!
3) patollie22 has applied to start work (Funders only: approve worker | reject worker).

I'm interested on this contract.....i don't have much idea about though
4) trytst has applied to start work (Funders only: approve worker | reject worker).

Trying anyway...n try try to get it's
5) tavion92 has applied to start work (Funders only: approve worker | reject worker).

123456789101112.):$:$.$.$,,$,$$$,!
6) ob593 has applied to start work (Funders only: approve worker | reject worker).

I’ll be waiting for the response thank You

Learn more on the Gitcoin Issue Details page.

[dckc]

@jeetraut I'm working with @thisispalash on some questions, and it would help to have more of the story. Suppose our hero is Alice. What does she do first? Does she make an offer to this forward contract? Or does she start by doing something else?

Does Alice start at something like https://satellite.money ? If so, how does she specify her Agoric destination? Does Alice start one of these forwarder contracts bound to her address? Or was the forwarder contract started by Bob?

precedent in provisionPool

We noted considerable overlap with provisionPool.js, which also stands by to receive funds and trades them on a PSM.

[thisispalash]

Okay, so I've been thinking over this bounty and my discussions with @dckc over the last day, and I'm thinking of two ways to go about this;

1. In the first way, the contract forwarder.js listens to incoming psm supported ERTP Assets, swaps them for IST, and deposits them back into the address / wallet listening to. This would presume every wallet would have to deploy forwarder.js and also perhaps have an option to turn the contract off, so not every psm supported Asset is swapped. This way is quite similar to the implementation of provisionPool.js which listens for deposits and swaps the deposit, only to deposit it into a different purse, but the same address / bank (purse definition, deposit (in swap(...))).
2. The other way, is where forwarder.js expects a lot of information (and authority) to function where in it is given the user's Purse along with the incoming Asset (as opposed to the Asset and the address), so it can swap with psm and deposit the swapped IST. A compromise could be that it instead returns a payment (ie, the paymentOut from the psm swap) to the caller who can then do the actual depositing. This way also has an added benefit of only one forwarder.js existing (with a mapping of Brand <> psm instance) and virtually anyone can interact with it.

In both scenarios, I presume the deployer of the contract sets up two main things,
i. The psm instance mapping,
ii. and, stuff for metrics / logging

@jeetraut You had mentioned in the initial call on the bounty that this (forwarder.js) would be somewhat like the last step in a series of contracts, and I think path 2 (with the compromise) above would serve this description. Am I right in thinking this?

The full package

Another way I was thinking of this entire thing was in the following way (inspired by provisionPool.js),

1. Alice comes to something like https://satellite.money and selects a source IBC chain
2. Alice then selects the token, amount, and destination on Agoric
3. The UI, under the hood, sends the txn to a common address / bank
4. The contract forwarder.js is listening to this common address / bank and it denom's the incoming txn for the token, path, and also the destination address in some way (perhaps as message bytes?)
5. forwarder.js then swaps the incoming token / Asset and sends it across to the supplied destination address. (Still unsure on how the deposit would work with just a String address and no Purse, but assuming that is possible)
6. If no psm instance is mapped to the incoming token / Asset Brand, the txn is rejected.

This is the complete solution route, which I am not sure if it is the way to go, or even needed.

[rowgraus]

@thisispalash
I think we want a design like you mention in (2) where the contract performs the swap on the PSM, but then sends a payment to the third party user's purse.

For your Full Package flow, the front end actually would not be satellite.money - it would be a Kado-provided front end that would allow the user to specify the Agoric address alongside making a credit card payment. Kado would handle getting the supported asset to the Agoric chain but would route it to this contract (along with data for the destination address). This contract would then perform the swap and send the assets. We had a model where assets could be sent directly using a 'board ID' - perhaps that would work instead of a payment? (@dckc). The rest of the flow looks roughly right.

[thisispalash]

I see. So the first thing I take from this is that there is no UI obligation for the contract. Secondly, the contract exposes the following functions,

• under creatorFacet
  • Initialize metrics/logging
  • Initialize mapping for brand <> PSM
• under publicFacet
  • swapAndSend that takes in supported ERTP Asset (sent by Kado) and some data with the destination address and also a Purse/board-id, swaps the Asset for IST and sends it along to the destination.

The only thing I am not sure of now is the board-id / Purse thing for the final sending of the IST to the destination; but I plan on attending the dev OH this week and can clarify it there.

[thisispalash]

Apologies I couldn't attend last night's dev OH. I didn't realize that daylight savings has happened and that the call was an hour later. Regardless, the #8114 issue should resolve the destination <> purse dilemma, with the only caveat being I am not sure that home is available to the contract. However, I remember @dckc saying that home is the union of local and agoric and I believe agoric is available to the contract (will have to double check). If namesByAddress is available through agoric and agoric is available to the contract, then I can deposit the payment in the destination purse / address.

Also, here is the repository where I am working — thisispalash/agoric-psm-forwarder. I have so far uploaded a draft version of the contract. The main questions that still remain are, i. managing the differences in ag-solo and smart wallet; and ii. how would testing, and subsequently deploying, work.

[dckc]

... I am not sure that home is available to the contract.

It's not. But deploy scripts have access to home, so they can pass home.namesByAddress to the contract at start-up, in the terms.

[thisispalash]

That would be like a snapshot at the time of deployment though right? I am presuming that namesByAddress is an object addressed by the agoric addresses currently provisioned. So, what happens if a new address is provisioned after the forwarder contract is deployed? Or wait, is namesByAddress like a function and hence we use E(home.namesByAddress).lookup(...)?

[dckc]

we talked thru this flow...

[dckc]

@thisispalash note #6490 is fixed in master now.