application for FIAT-on-off-ramp #348
Conversation
|
|
There was a problem hiding this comment.
Sorry for the late reply and thanks for the application. In general sounds like an interesting project. Could you potentially update the milestones according to the original template? And include information about the license, tests, documentation, programming language etc. Regarding the concept, what are potential attack vectors? For example, is it correct that if I trade my tokens with someone else (for example I buy a coffee) and after this I empty my bank account, the token itself disappears? Also, can’t this system be exploited, by spending the token as well as the money in the bank at the same time or puts a lot of power into the oracle/bank? But maybe I’m missing something here.
|
Hi - I added the changes you requested. Regarding your questions a quick reply as well:
Added to the md-document.
No - but you described an attack vector - see risk mitigation strategies. Nevertheless we see value in our approach, because in many use-cases the beneficiary of the bank account is actually the same person who wants to receive the stable-coin (=Fiat funds), just think of over-the-counter businesses or digital assets: Once asset-tokens are bought, they can float for themselves. Our part is the transparent conversion between Fiat and these tokens. That is why we call it on- off- ramp. The goal here is not to create just another stable-coin, but we focus a mechanism to sync transparently with a pegging account with a Smart Contract. Me might also remove the "transfer" function entirely, maybe that makes it safer and maybe even clearer.
Yes, power is on the oracle or the bank. Same problem exists in real world e.g. when buying a property, escrow accounts run by lawyers solve that problem. In our case an escrow could use Smart Contracts to digitize his services. Thx |
There was a problem hiding this comment.
Thanks for the update. In general, I’m willing to give it a try and will share the application with the rest of the team. One thing you might want to change are the parts about “parachains”. For example, I suggest replacing “Implement Parachain with the FIAT-stable-coin” with a “Implement substrate based chain...”. Also the diagram with the RelayChain doesn’t look correct to me. For a poc it makes sense to initially just focus on a simple substrate based chain anyway.
Noc2
added
ready for review
|
Hi - thx a lot for feedback; I did a small merge based on your second feedback, regards - Walter |
|
So if I understand correctly, Milestone 1 doesn't provide any Polkadot-specific deliverables - it's purely a Java app, right? I guess users would be able to run it either locally by building from scratch, or use the provided Dockerfile to bootstrap a Docker image, launch a container and interact with it? I don't quite see a link between M1 & M2 at the moment. Do you want to have the off-chain worker communicating with a Docker container built in M1? Lastly, will users be able to link and query their actual accounts upon completion of M1 already? Do you have a list of banks that will be supported? For example for Swiss banks, a quick google search on "EBICS + < top Swiss retail banks >" shows that this is indeed supported, but only for corporate clients (e.g. CreditSuisse DirectLink, UBS KeyPort) |
True - the first version of the grant-md-file, M1 also contained a pallet which wraps the API, but I thought its clearer like that.
Yes - means get daily statement and create payments.
Yes - the off-chain worker communicates with the docker-image built from M1
Yes
I dont have a list, but you may assume that almost every €-bank in Europe (plus Swiss banks) supports this international standard. But every country may tweak standards a little, also Switzerland did. I have operated with Swiss, Dutch and German banks, but I assume compatibility with different countries will not be a big issue, because we need just a small part of the standand (pain001, z53). That only corporate clients are eligable to get the interface - I was not aware of. I guess that is a banks descision. I hope getting that is not be a big deal - my bank (Hypo Lenzburg) is actually a very small Swiss bank, and it was no problem at all. For banks, Ebics is daily business and they use the same system for private and corporate clients. There are many applications which are able to read or generate pain001 or z53 in order to sync with bank-accounts. There are also sandboxes for Ebics - so you dont need to test M1 with a real bank account; e.g. https://prototypefund.de/project/libspsd2-freie-api-und-sandbox-fuer-das-europaeische-finanzsystem/ We never used an Ebics-Sandbox so far, but I guess that will make sense in this project. |
There was a problem hiding this comment.
Sounds good, thanks for the replies.
I won't know it for sure until testing your solution, but it seems that the barrier to entry for users is still somewhat high, as the integration with the bank's side might prove tricky and very custom for each bank. But I'm no expert on this, let's see.
Good luck with the project!
|
I agree this could be an interesting project and in the best case serve as a basis for future integration between blockchain and traditional banking. However, the proposed scope (which is maybe all that's possible at this stage) is still very limited. Do I understand it correctly that the on-chain accounts would basically mirror the state of the linked bank account, but not provide much functionality? I.e. these stablecoins can't be used for anything other than being burned in order to trigger a bank transfer. They are worthless for most purposes as I can always withdraw all the funds from my bank account and they will become unbacked, which means I can't send them to anyone, trade them for another currency or use them as collateral. The only thing I gain is being able to trigger bank transfers from the blockchain and publishing my bank balance and activity for everyone to see ;) Now, I'm sure there's some potential I'm not seeing, so what would that be? And what would you need to accomplish in order to get past this barrier? I also don't see how transfers would work, you state that "anyone who holds stable-coins in his wallet or contract, may burn the coins and 'cash out' FIAT". But anyone who holds stable-coins in his wallet already has this in fiat. Or how else would you intend this to work? Let's say you send me some of your stablecoins, then does the same amount disappear from your bank account and if so where does it go? And otherwise what's stopping you from emptying your bank account before I cash out? |
Yes. The focus of this project and the first grant and MVP is mirroring a bank account, so that’s the functionality. But of course you can use that in any Smart Contracts or other pallets, so use cases are not limited.
I think that statement does not catch it. First we want to create a mechanism for Fiat on- and off ramping, and not just another stable coin. Of course you can create a transferable stable-coin based on the Fiat-on/off ramp (and its the most obvious use-case), but also other things like digital assets/shares or a token which represents participation rights (we gave the example of crowdlitoken.com), or create any Fiat/token exchange similar to Coinbase. But if you create a stable-coin and and if you claim that the coin is fully pegged then you can also do this via an e.g. transparent DAI pegged contract which always satisfies “market cap stablecoin <= pegged DAIs” when minting/burning. Second it’s about what you claim to do with the Fiat value you receive - issue a stable coin, digital assets, and arty NFT etc - it does not matter in terms of proposed tech here. The first grant is all about the tech which is about recording/capturing what is happening on a bank account and triggering a payment without bothering with IBAN-account numbers in a smart contract.
Yes - that is true. But publishing means to have a “blockchain-proof”, which provides a claim for other things, not just as a published bank balance or transaction. E.g. as a basis for yield-payments after an investment.
We hope that being able to capture an incoming bank-transfer on a chain and to trigger an outgoing payment transaction is already good enough, because its quite painful to work with bank-apis from scratch, and we think that a tested open-source project would be very helpful for the ecosystem. But the biggest potential we see is usability: End-users may transfer value to smart contracts by using a simple wire transfer, no wallets or cryptos needed. Still end-users may benefit from a real, transparent cryptographically secure “blockchain-proof” without owning a wallet or managing wallet addresses. In order to run a real-world smart contract, you do not need coins and wallets to make the ledger work. I don’t want to stress this argument too much, because it would raise more questions and make things too complicated.
Two use cases get mixed here. First use-case is that someone trustworthy (or an escrow) issues a fully stable-coin like TrueUSD, second case is that someone offers digital assets like crowdlitoken.com, which “sells” something and the issuer is the same entity as the beneficiary of the pegging account. Both cases are valid and supported. We were explicit in the grant that we do NOT want to use “Currency” trait in a smart contract at the moment, because now it is all about getting the Fiat sync done ... which supports both cases. Regarding the question related transfer: Transferring coins is easy, thats clear. Cashing out means “burn” in our case - the API for burn is “burn(amount,clue)” - the key here is the “clue”. Please check back with the grant-documents, we described how this would work. Maybe it's unfortunate that we are using the same terms for the events here - burning stablecoins and the off-ramping of fiat- I guess we should change that.
Misunderstanding here is I guess the mix between tech and application of the tech. In case of a fully pegged stablecoin its crucial you trust the issuer. So yes - if you are the issuer and you claim you run a pegged account we have the “Tether question”. But in case you sell shares, assets, or you want to shape-shift Fiat payments to some other token, the pegging-argument does not matter. If you buy DOT on Coinbase, you need to trust coinbase that you get the DOTs, before you actually see the dots in your own wallet. With the system proposed here, you can e.g. create a smart contract which sends you DOTs to your wallet, based on a Fiat transaction, just like Coinbase. In this grant we don't care what you do based on a Fiat payment, but we want to provide code the on- and off-ramp of Fiat payments, so that you can build on it and do whatever you want, e.g. create a Stablecoin, or a “private stablecoin” which can be used on platforms similar to coinbase, where you first “upload” Fiat funds to buy cryptos or whatever. To answer the question: transfer does not make funds on bank account dissapear, only burn(amount,clue) does. And nobody stops you from emptying the account - a question which is less relevant for use cases other than publicly traded and fully pegged stablecoins. Sorry I took I bit more time to answer - I just went of for a short holiday break with family. |
There was a problem hiding this comment.
Thanks for taking the time to provide such a detailed answer - it has now clicked with me and it does sound more interesting than I thought. I agree this would already have a couple of valuable use cases in the proposed state, plus serve to break new ground. Happy to give my vote!
|
Congratulations! As part of the Open Grants Program, we want to help winning teams acknowledge their grants publicly. To that end, we’ve created a badge for projects that successfully delivered their first milestone. Please observe the foundation’s guidelines when making any announcements; in particular, don’t announce the grant publicly before you've completed at least the first milestone of the project. |
* add application * feedback to CR * added second feedback Co-authored-by: walter.strametz@gmail.com <walter.strametz@gmail.com>
…-application grant application for the governance OS (Nuclei Studio OÜ)
|
@wstrametz could you submit an amendment on the timeline? It's now been 5 months since your last delivery and it's probably time to update the application to match your current roadmap. Feel free to include any other changes you'd like to make to the application. |
|
@wstrametz friendly reminder. For the record, Walter reached out to me on Element shortly after my last comment to let me know the team would submit an amendment soon. |
|
Hi Aleixo - thx a lot, I appreciate. I sent the update to Dastan
(Polkadot-dev) on Sunday, he will give me feedback today and I also asked
him to give a commitment for the finish line. Thx, Walter
Am Mo., 10. Jan. 2022 um 19:50 Uhr schrieb Aleixo Sanchez <
***@***.***>:
… @wstrametz <https://github.com/wstrametz> friendly reminder.
—
Reply to this email directly, view it on GitHub
<#348 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANV4FN2H4IX2DN7WLUBZGZTUVMS7ZANCNFSM42KFWJZA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
DI Walter Strametz, IMD Executive MBA
// Founder element36.io
Mobile/WhatsApp: +41 77 2598916
Skype/Telegram ID: wasabrot
LinkedIn: http://bit.ly/2oPsTSw
<http://www.blockchain-real.at>
|
|
Hi @wstrametz, would you mind sharing an update on milestone 2? According to my calculations, your amendment envisaged a delivery in early February. |
|
Hey @wstrametz, are you still interested in this? Note that if we don't hear from you within the next two weeks, we will assume you're no longer interested and terminate the grant. |
hi @alxs - yes, but I guess we needed a bit of a push - @dastansam (main developer) had personal issues, his familiy lives next to Russian border. Lets me check back with him and I let you know. |
|
Best wishes to him. Here as last time, it would be great if you could submit an amendment unless you're ready to deliver. |
|
Hi @alxs - Dastan working on it; should not take too long. Thx |
|
Hi @wstrametz @wasabrot any updates on the status of M3? If it has been delayed further can you please submit an amendment to extend the estimated deadline? Thx |
|
hey @keeganquigley, I talked with Alex about this in our Element chat and we agreed on making an amendment PR. I just opened it here. thanks |
|
Hi @wstrametz just checking in to see if you can give us an update on M3? |
|
hey @keeganquigley we are submitting it soon, just need to finalize the documentation and tutorial |
Grant Application Checklist