Aerenity - bring USDT and other stablecoins to AE

mhhh, this seems to be a bug in mdw. can you create an issue there? @FerumFlex

=> https://github.com/aeternity/ae_mdw/issues/new

2 Likes

Hi guys, finally after a lot of small problems(probably not of them are solved). I was able to finish alpha version of exchange usdt eth → usdt ae. Please check video

and you can try using this link

It could have some problems, I am working on fixing them. You can write there.

3 Likes

Added issue to mdw

1 Like

@FerumFlex so right now the swap in both directions relies on an oracle to confirm that the tokens have been locked (Ethereum) / burned (æternity), is that right? or is it different when swapping the tokens from æternity to Ethereum?

will describe how it works right now.

  1. User fund gate contract with some USDT tokens. And if something goes wrong he can get his money back.
  2. Oracle adds signature to the swap. It uses ecverify to verify that signature is correct.
  3. Client waits for signature
  4. Once it gets signature, it can claim funds on ae side. Ae side also verifies that signature was created with oracle. If all is good it mints tokens and sends to user.

Yes it is different from htlc contract, because for that contract you should have some tokens minted already. In this case you always have value on ae tokens. Because you can always swap them back to usdt on ethereum. So that makes them valuable.

ok but this is still from Ethereum → æternity, right?

how is it done from æternity → Ethereum?

Same thing.

  1. User fund gate contract(AE) with some USDT tokens. And if something goes wrong he can get his money back.
  2. Oracle adds signature to the swap. Contract burns those funds.
  3. Client waits for signature
  4. Once it gets signature, it can claim funds on eth side.

It has one oracle address. and this is ethereum adress. Oracle has access to private key and can sign messages.

1 Like

would be nice to have a (more) detailed & up to date sequence diagram which explains the whole process. also how to deal with edge cases.

you said e.g. that user can get the tokens back from ETH contract if sth. goes wrong with swap. how is that covered?

you said e.g. that user can get the tokens back from ETH contract if sth. goes wrong with swap.
how is that covered?

when user funds contract with token. this is htlc contract. if oracle can not add signature to some time(1 hour for example) you can call fundCancel and it will return your tokens. That call is allowed if time passed and oracle did not sign this swap.

right now in alpha version you do not have interface for this. it is in development. you need to know swapIds that can be refunded. I am planning to build small api that will return swaps for addres and their status. This information is already onchain, api just will make it more useable.

would be nice to have a (more) detailed & up to date sequence diagram which explains the whole
process.

Yeah will find some better tool to do this.

also how to deal with edge cases.

what edge cases I did not cover? Idea is if you send tokens to gate after sometime they can be refunded (if not signature was added). If you have signature you can easily claim your money on other contract.

2 Likes

so the Oracle will always be the middleman and has to provide signatures on Ethereum as well as on aeternity for swaps in both directions, right?

yes, best idea that I can right now imagine)
It could be several oracles. for example 12 and to treat swap successful you need 6 confirmations.

It will be good it someone can check contracts for both sides(eth and ae)

and maybe find some issues or bugs.
I wrote also tests for them. In the future will add more cases.

4 Likes

Looks super cool, I like seeing that it also includes test cases!

I have 2 questions after having had a quick look.

  1. it does require liquidity providers on the receiver side, right?
  2. in the sophia gate contract bridges seem to be defined and managed, but not really used, is this on purpose?
3 Likes
  1. it does require liquidity providers on the receiver side, right?

If understand you question correct. it does not require LP on the ae side, every time you do ETH → AE it does minting tokens on AE side, when you do AE → ETH it burns tokens. Idea is always have liquidity on the ETH contract. so every AE USDT token has exact amount of locked tokens in ETH smatcontract. In this case AE USDT tokens have value)

  1. in the sophia gate contract bridges seem to be defined and managed, but not really used, is this on purpose?

It is used in fund functon in Gate.aes. Goal have a pair of two addresses AE and ETH side. In general we can create a lot of different tokens for this. Like USDC, TUSD, just adding bridge to the contract.

3 Likes

@all Need you opinion of how we will run it into production. So right now this solution requires oracle, that oracle should sign swaps. We can have as many oracles as we can and can have some consensus. For example we can have 10 oracles. if 5 of them sign swap, we treat it as confirmed. Those oracles can get revenue from swaps. For example 1%. So several polls, please vote)

Should bridge take fee?

  • yes
  • no

0 voters

How many oracles should we have

  • 1
  • 2-6
  • 7-12
  • ‘>12’

0 voters

Who should be responsible for oracles?

  • author of the tool
  • core team - aeternity
  • some crypto exchange(s)
  • some aeternity projects(please write which one in comments)
  • some other organizations(will write on comments)

0 voters

3 Likes

I think we should set up a Dao to be responsible for operation and maintenance

2 Likes

you mean this operations, adding/removing oracles and stoping for maintance/start gate?

On #1. Have you looked at what PortalDefi is doing?

On #2. It seems risky for the AE team to have such a responsibility. If there is a big problem and huge loss, this could impact the team. It needs to be structured so that the AE team is insulated from such potentially legal of public relations problems.

1 Like

A potential edge case might be found at the moment the AEUSD is minted. What can a bad actor do on the Ethereum chain at the immediate moment the AEUSD is minted? If there is even a 1 millisecond of an opportunity, it could be catastrophic to the project. I do not know how robust the HTLC is in terms of resisting such an attack. I suppose, if all technical features of existing stable coins is replicated, it should be as secure.

By the way, have you looked at Bitcoin Gold’s version of a bridge yet? Built for AE <–> BTG

1 Like