Dear Hyungsuk Kang, thank you for your application! We will look into it as soon as possible.

I had a quick look, and I noticed the following information missing/incomplete:

• Your total costs are less than the sum of the milestones,
• project name, team name (see here),
• technical experience with Substrate, Polkadot or blockchain in general (I also couldn't find much information on Digital Native Foundation anywhere),
• development status (given the technical details you provided, it appears that you already spent some time working on this),
• comparisons with other projects, element36 comes to mind.

I'm afraid I was unable to read the bok.or.kr article you linked to. Could you expand a bit on the legal setup you are aiming for and the current situation in South Korea? For example, Gingko Bank would have to perform KYC for all customers, right?

Lastly, I took the liberty to push some smal edits to your repository. The markdown syntax was a bit off, which made the document hard to read. I would have submitted a pull request, but that seemed to be not working. Feel free to correct anything I might have gotten wrong.

I just saw element36, and it is true that the proposals share the same goal, but we try to come up with the different technical design.

1. We assign total supply to the bank digital currency to prevent bank run where crypto market crash and everyone wants to convert crypto to fiat.
2. We come up with multi-layered access on operating bank digital currency by separating roles for pauser, minter and admin to assign roles.
3. We think we are currently working with api which is compatible with KRW only, but we are checking if the api is shared worldwide.
4. We use queues to detect addresses that needs to be processed with off-chain workers regularly checking status by the bank instead of using off-chain worker in runtime.
   And yes, Ginkgo bank will have to go through KYC process, and the blockchain would need a certain identifier created by the bank or some did solutions like Litentry.
   Bank of Korea seems it blocks foreigners to enter their website, but here is the pdf file related to the article.

@hskang9, thanks for the info. Could you please amend the PR to include the information mentioned in my first four bullet points?

Also, could you provide more information on these "bank digital currencies" you speak of? How are they different from the common stablecoins? The way I understand it, you want to make crypto-to-fiat-to-crypto swaps easier, so I can swap for KRW instead of a stablecoin?

Sure I can. so "bank digital currencies" that I speak of is different from common, fiat-collaterized stablecoin(USDT, USDC) in that it relies not only on counterparties and external audit organization, but applies trustless way where all records of inflow/outflow of fiat asset with the record made in chain. There is often an article that the amount which USDT is backed by USD is unsure, because there has not been a specific tx that USDT is actually come from a fiat asset.This will make fiat-to-crypto swaps easier than before with just simple KYC, and technically it will allow swapping digitized KRW in the blockchain. The price of digitized KRW can vary from the supply and demand after listing in specific exchanges, but the system will guarantee 1DKRW(digitized KRW) = 1KRW with the automated bridge managed by private banks or other custody organization.

Can you expand on this "trustless way" in which fiat in- and outflow is made? Wouldn't there have to be a legal entity taking responsibility for the fiat?

The legal entity taking responsibility of the fiat will be Ginkgo bank, where it provides funds from theirs too. Payment Gateway api is provided by the Payment Gateway provider. We also need another auditing firm on managing fiat for Gingko Bank. However, on digitizing the asset or changing crypto to fiat, only systems built with payment gateway api and bridge offchain workers are doing the job, achieving consensus without participants having to know or trust anything but the system itself. I will amend some details regarding with end-to-end sequence on each side(fiat-to-crypto, crypto-to-fiat). I might need to add storage for identifier for bank's database keeping the fiat account.

I will amend some details regarding with end-to-end sequence on each side(fiat-to-crypto, crypto-to-fiat).

Please do, because I still cannot picture this being done trustlessly. Also, please remember to update the application to address the bullet points above.

@semuelle I have done specification regarding the development status. Adding container architecture soon.

I cannot assure myself that this is "trustless" in that the word is often misdefined from dictionary and have narrow meaning in crypto. However, I think I am building platform for hybrid finance where crypto and fiat can be accomodated together

@semuelle can you review the changes that I have done for bullet lists?

Hi @hskang9, thanks for the updates.

So the Initiator and Processor are clients running under the control of Gingko Bank, correct? Because only they should be allowed to initiate transfers from and to Gingko accounts. Since this is a highly specialised software that serves a proprietary backend, I'm not sure this is something the grants committee would want to fund. Or am I misunderstanding?

Hi @semuelle, thanks for the review.
so Initiator and processors are modified cron client of lumen that we have, and Gingko Bank can run it. However, it is incorrect that they should be limited only for Gingko Bank. The project is open source, other banks can modify the clients to adjust to their own standard. Also, this software is not specialized in that the apis are based on open banking. We never said that we will use api that is closed source. Korean fintech has been developed that all banks share the same api to manage their online bank account, so the solution that we make is highly compatible in Korean banks. In conclusion, this is rather a framework to digitize fiat asset from Korean banks. Gingko bank is just a company who wants to experiment this solution. We are willing to extend this solution to accomodate with other fiat-related apis that element36 team provide here or there by other payment gateway companies in Korea.

Also, Gingko Bank does not even have full control in this framework. We have multi-role access approach to manage the solution, and we currently have a reference from our deployed smart contract library file here.

@semuelle I thought grant project was all open-source and has public access to all? What makes you make overassumption that we are making a proprietary software? Also, I wonder a grant is not available when an open source project is run in control of a company?

Hi @hskang9, thanks for the replies.

You are correct in that our grants programs require grantees to publish code under a open source license, and that the ecosystem as a whole can benefit from it. Some applicants are not aware of that, and some otherwise good applications fall through in that regard because they contain some form of centralisation that is hard or impossible to replicate. Software that, in essence, requires a banking license to function effectively would be such an example. It is my task as evaluator to make sure that these hurdles are not too large or manifold. Since Gingko Bank electric cash account is part of the sequence diagrams, but not part of the deliverables, I assumed this would be hard to replicate. If it is based on a publicly available API spec, I am happy to go forward with this. While a banking license certainly isn't easy to obtain, I can see that you have put considerable effort into making this usable for and compatible with other providers. I will therefore now share this application with the rest of the team.

Regarding the multi-role access approach: since I don't know who gets to assign the roles and what criteria they are assigned by, I still consider this centralized.

we currently have a reference from our deployed smart contract library file here.

So you have a working version on Ethereum? Can you share the contract addresses and/or URLs?

Closing for now since the team is already working on another grant. See #244 (comment) and @hskang9 as I said, let us know in case you really want to work on both grants in parallel and we'll discuss it. However we'd likely expect you to at least deliver milestone 1 first.