conFIEL CBDC

conFIEL CBDC is a proof-of-concept for building a retail-CBDC on top of XRP Ledger for Mexico’s Central Bank (Banxico) using SAT (Mexican IRS) digital signatures called FIEL (or e.Firma).

Comment

conFIEL

Powering CBDCs in Mexico using FIEL-derived custody wallets

Inspiration

conFIEL CBDC is a follow-up of our first iteration of conFIEL, which focused only in key management. conFIEL CBDC takes the concept a bit further by leveraging the XRP Ledger native features to allow online and offline payments between users.

For this iteration, conFIEL focused in the following challenges:

  • Incentivating users to get registered into a new system within a commercial bank, and
  • be able to take payments despite not being registered into the system.

Since 94% of the Mexican population has smart phones, and some communication channels are subsidised by major telecomm companies (e.g. WhatsApp), we can quickly onboard users by supporting offline payments, where the "settling" of the payment can be sent via a separate channel, and can then be claimed once the user is onboarded.

What it does

conFIEL CBDC is an infrastructure project focused in the Mexican market that showcases how easy is to onboard users into the XRP Ledger ecosystem by using the over 30 million deployed digital signatures used by the Tax Revenue Service in Mexico ("SAT"). Via conFIEL, any user already reporting their taxes to the Mexican government, has everything needed to get a digital wallet ready to use with XRP Ledger.

Additionally, conFIEL CBDC leverages on Escrows to use Commercial Banks as trustees for offline transactions. These escrows can hold payments for individuals that have yet to be onboarded into the system, but have a uniqued identifier (in this case, the "RFC", similar to a public SSN for taxes), and thus, can be forwarded by the Bank once the escrow is settled.

The Escrow rely on the Pre-Image Sha256 feature, which means that someone can send a payment to another individual alongside the "secret" needed to unlock the payment. This ensures retail can do peer-to-peer payments, but only via agreed Commercial Banks that have KYC-ed the user via this Tax Revenue Service Digital identity (ie. the FIEL).

How we built it

We leveraged the standard RFC1751 to provide existing RSA-2048 private keys with the ability to use a signed message as a derivation path for an XRP Ledger. Additionally, we created a small UI to showcase the workflow and how this derived wallet can be used to transfer value in the XRP Ledger.

Further, we pre-loaded wallets for the banks (which in an ideal world would be within a proper custody system like AWS Nitro + AWS KMS or a similar Intel SGX-like enclave) to be able to forward payments given on escrows. We created escrows that can be settled via a secret (i.e. "fulfillment" within the XRP Ledger syntax), allowing doing offline payments such as two people can share the "receipt" of the payment, and the payee can then claim it to the bank that holds the escrow.

How to test it

Go to http://omawww.sat.gob.mx/tramitesyservicios/Paginas/certificado_sello_digital.htm and download the set of sample certificates issued by the SAT (select "(383 KB) Certificados de Prueba"). Unzip the contents in a directory you can reach. Go to https://con-fiel.vercel.app/demo and select any "Persona Fisica" and pick the ".key" and ".cer" file in the same folder. The password is "12345678a" for all keys.

Important: If you type the wrong password, an error will be shown in the demo. Please refresh to restart the process from the beginning.

Important pt2: If you have used the app multiple times, you'll see some wallets have already some funds. You can change the derivation path of the wallets by adding "id" to the query parameter of the app. E.g. https://con-fiel.vercel.app/demo?id=64

Challenges we ran into

As most digital wallets, the wallets use by XRP Ledger rely on the popular digital signature algorithm ECDSA. RSA private keys do not share the same signing properties as those used by elliptic curve-based signing algorithms. We had to explore options on deriving a meaningful amount of private data (to avoid collisions) while still being able to have a deterministic XRP wallet that could be used multiple times.

The documentation around Escrows and the technicalities around them are not always obvious. We had to do a few trial and errors around the EscrowFinish and EscrowCreate methods to get it right. Also, the "CancelAfter" and "FinishAfter" have some interesting properties that are not immediately obvious. Finally, as the application grow, the storage of state and data became complicated, which for this demo was manageable via localStorage in the browser, but ideally we would have it in a proper database.

Accomplishments that we're proud of

The derivation strategy for XRP ledgers is similar to existing L2 solutions in the blockchain ecosystem, but not many have explored using RSA or similar keys. It's always easier to use the newest and "coolest" cryptographic primitives in the market (e.g. EdDSA), but being able to use "old" private keys which is most of the time already deployed by the millions in multiple countries’ infrastructure, is something we are proud of.

Being about to send offline payments via Escrow is a very unique value proposition feature for this project, as we can achieve both an incentivisation mechanism for new users as well as allow peer-to-peer settlement between non-connected users by simply showing the Escrow transaction. The fact the XRP Ledger supports it out-of-the-box was incredibly useful.

What we learned

You can map almost any existing bank-focused CBDC, hybrid-CBDC or retail-CBDC with Escrows and Checks. Ideally, you want to use Commercial Banks as trustees or issuers of either of these transactions, and keep a database with their respective connections to the user. However, once you have that layer, you can pretty much develop a fully-functional CBDC system on top of XRP Ledger.

For now, it is not very clear how privacy could be achieved under this model, though.

What's next for conFIEL CBDC

We are now sure that we want to go through two routes:

Built With

Share this project:

Updates