The future of on-ramps is peer-to-peer
At Ramp, we’re constantly at work to bring you the best on-ramp experience. And while we’ve received a lot of praise from our users and partners, there’s more to be said about on-ramps than simple pleasantries.
In this post, we’ll take a closer look at how Ramp operates to understand some of the challenges of fiat on-ramps. We’d also like to share our ideas about what their future might look like, as well as a few of our latest developments.
Story so far
One of our insights is that because certain restrictions have been imposed on money-handling institutions, the first-generation on-ramps became centralized and fragile. Existing on-ramps are often based on models that share two similar characteristics: geographical locality and reliance on credit card rails. Since these models are custodial in nature and rely on business partnerships it makes them both vulnerable to legal risks and costly to operate.
In some models, the on-ramp is based on creating multiple subsidiaries in each legal jurisdiction they’d like to cover. This requires obtaining multiple payment institution licenses (or their equivalent) which incurs increasing legal and operational overhead. On top of that, there’s always a risk of significant relationship going south, for example, bank denouncing the bank account used in on-ramp operations.
It is often the case that the on-ramp is implemented using credit card rails. High transaction fees and transaction limits are the main drawbacks of this approach. This is because the credit card processors associate cryptocurrency transactions with increased compliance risk. In this method, the on-ramp operator is also at risk: Combating chargeback frauds often results in significant transaction premiums.
Existing on-ramps spend a lot of organizational resources in an attempt to solve inherent flaws in those approaches. While they manage to keep things afloat and provide a reasonable level of service, we believe that they will fail to operate and scale in the long run.
Instead, we propose a solution that relies on individual users’ relationships and immediate access to the banking system granted by law. The settlement in Ramp is based on banking data provided by Open Banking. By connecting to bank APIs directly, Ramp makes it possible to settle transactions based on financial data of its users.
How Open Banking enables better on-ramps
Open Banking enables compliant, legally and technically sound access to banking data and payment services that form a basis for the functioning of innovative fin-tech applications. It is a global trend with legislative support in the UK (“Open Banking”), Europe (“PSD2”) and growing support in the US and Asia.
With Open Banking, Ramp aims to create an open, non-custodial protocol that enables fiat on-ramps. It will operate as a peer-to-peer marketplace where liquidity pool owners (sellers of cryptocurrency) provide liquidity to end-users (or, the buyers). We’ve already introduced two key elements of this system: Ramp Instant and Ramp Pools.
Open Banking enables us to access banking data on behalf of the bank account’s owner. With the bank account owner’s permission, we can gain “read” or “write” access to data. “Read” access enables us to confirmation of transaction payment, while “write” access allows us to create wire transfers.
In our products, we employ Open Banking to implement otherwise cumbersome processes of on-ramping.
- With access to banking data, we can perform KYC without extra steps such as uploading your ID or driver license.
- Because access to banking data is mandated by law, there is no inherent risk in dependency on Open Banking. This effectively reduces deplatforming risk close to zero.
- As more jurisdictions deliver to their legal obligations, we expect significant growth of the availability of Open Banking in the UK, Europe, and soon all over the world.
- Thanks to Open Banking, transaction settlement in our system is agnostic to the method of electronic funds transfer. This means that our users can choose from a multitude of payment methods, including payment directly from their bank account, and enjoy low settlement time and low costs.
- One of the functions mandated by Open Banking is payment services. With user approval, we can conduct payments on their behalf, reducing inconvenience with payments to one click.
Settlement in Ramp
The actual exchange settlement in Ramp can be outlined in a few simple steps:
- Alice wants to sell her crypto. She creates a liquidity pool using Ramp Pools.
- Bob wants to exchange fiat for crypto. He uses Ramp Instant to start a swap.
- The crypto is drawn from Alice’s liquidity pool and secured inside the escrow smart contract.
- Bob learns the payment details and wires payment to Alice from his bank account. Bob can delegate this step to Ramp and create a payment in one click.
- When Ramp detects wire transfer payment (using “read” access) the escrow is released and the exchange is settled.
Trust issues
The description above reveals that Ramp is responsible for providing smart contracts with banking data. This creates a dilemma known as the Oracle Problem. Ramp, being the sole oracle in this system, is encumbered with the trust of all parties involved in the exchange. We recognize that this setting is not preferential, as it poses a risk for both end-users and liquidity providers: it’s technically possible that a malicious oracle could feed the smart contract with false information, leading to settlement fraud.
Reliable oracles are essential to ensure the security of settlement, as well as enable scalability on a large scale: Any properly licensed entity could utilize its privilege to access financial data to participate in the settlement. In the long run, this would lead to increased geographical availability and bank coverage, and a higher level of services.
While the Oracle Problem is not novel, it remains largely open. A lot of projects are tackling this issue in different ways, but we are yet to see one that would meet our requirements:
- Access to bank APIs is limited to financial/licensed institutions (AISP). The oracle would have to complete the licensing process in order to operate in our system.
- Financial data is sensitive and access to bank account data cannot be freely shared. This makes using third-party oracle services unfeasible.
- Under GDPR, financial data cannot leave the EU and is otherwise diligently protected. Oracle solutions without locality guarantees are not satisfactory in our case.
During our research, we decided to create a custom solution to fit our specific needs. We’ve created a compliance-first application that allows us to provide data to smart contracts in a trustless, transparent and verifiable way.
Our approach to oracles
tldr
We developed an oracle integrated directly with bank APIs by taking advantage of the AISP license. It operates in a secure enclave based on Intel® Software Guard Extensions (Intel® SGX) and is capable of performing remote attestation. Remote attestation helps us prove the security of the enclave, and by extent, the authenticity of banking data. Using the on-chain oracle registry, integrators and end-users can verify the soundness of the oracle and trace origin of the provided data.
Verifiable computation with Intel SGX
Trusted Execution Environment (TEE) is a secure environment for code execution located in the main processor. The TEE provides computation conducted inside of it with few interesting properties:
- It ensures the integrity of the computation, meaning that the platform operator is unable to influence or change its outcome.
- It ensures the confidentiality of its assets, meaning that secrecy of the data is guaranteed during transport, computation, and storage.
Intel SGX is a set of security-related CPU instructions that allows the creation of protected memory areas called enclaves. Intel SGX effectively enables the creation of user-defined TEEs on modern Intel CPUs.
Intel SGX supports attestation, which is a process where one party can increase their confidence that another party is host to an enclave. In effect, this process allows us to prove that a given set of computations took place inside the enclave. One of the supported modes is remote attestation procedure that involves Intel as a verifier, and thus it takes the role of trusted third-party.
This procedure has a following structure:
- The remote attestation is conducted by the attestor, who challenges the attestee to prove the security of their enclave.
- The attestor requests measurement of the enclave from the attestee, who is host to the enclave. The measurement of the enclave (or “the quote”), is a set of configuration information that describes properties of the enclave, including its source code.
- The attestor sends the quote to the verifier, which in this case is the Intel Attestation Service (IAS). In response, they receive an attestation report.
- The attestor verifies the attestation report’s authenticity. Knowing the enclave configuration (including its source code) and the contents of the report, the attestor can conclude whether the enclave is secure.
With remote attestation, Intel SGX enclaves allow multiple parties to co-create an environment for secure, confidential and verifiable computation.
Verifiable oracles with Intel SGX
Using Intel SGX is one of the pioneered approaches in oracle development, and it’s easy to see why: Confidentiality and integrity are both desirable security properties for smart contract data feeds, while remote attestation enables a mechanism for verification of data authenticity.
We can verify the attestation report using a smart contract to create an on-chain registry of oracles. To complete registration, the attestation report must adhere to a set of requirements specified in the oracle registry (“enclave policy”). The enclave policy ensures that all parties involved in computation (or in our case, exchange settlement) can in advance verify the security of the enclave and inspect its source code. Once the oracle is registered this information can be used to trace the origin of the data and it’s validity.
Using the on-chain registration component ensures transparency and openness of the system. It also serves as a “Rendez-Vous” point for parties involved in performing trusted computation. This component also ensures that participation in the system is mandated by the technical capability to provide sound banking data information.
Once oracle registration is complete, it can be tasked with enabling the transaction settlement:
When the oracle is notified about the task, it will receive a set of information describing expected wire transfer payment (“transaction spec”). It will also receive an encrypted access token permitting read access to transaction history in Open Banking APIs.
Oracle will fetch and filter data to find the expected transaction. If the transaction exists, the oracle will form a cryptographic proof that can later be used to settle the exchange.
The proof consists of transaction spec and relevant elements of transaction history, as well as metadata necessary to prove the identity of Open Banking APIs. This set of information is necessary to undeniably prove the origin of the data.
The oracle signs the proof with the secret key securely stored inside the enclave. Given that the attestation report proves the security of the enclave and the source code is publicly available we conclude that this particular key can only exist inside the enclave and can only be used if the proof is correct.
The proof is then used to settle the exchange and the locked cryptocurrency is released to the correct party.
Our efforts to solve this issue were two-fold: Firstly, we applied for an AISP license to ensure direct access to data in compliance with GDPR in Europe. Secondly, we’ve completed an R&D project to implement an oracle in Intel SGX based enclave.
We’ve successfully integrated this solution with Ramp Instant and we’ll soon release the beta on the Rinkeby testnet.
Security, scalability and the future
We believe that providing a reliable and secure bank data access layer is pivotal for successful on-ramp. By extension, bank data oracles are also significant to long-term ideological goals of Ramp: creating an open, secure, trustless, peer-to-peer protocol for the exchange of fiat and crypto.
In the future, the settlement layer of Ramp will consist of independent oracle operators. Similar to pool operators, oracles will compete to provide the best rates, experience, and service level for end-users. We want to eventually engage API access providers all around the world to participate in the network. In order to do that effectively and at the scale, we need technical solutions for network participants to verify the authenticity of the data.
We think that providing banking data to the blockchain ecosystem opens a broad spectrum of use cases. Our oracles can be used as a general-purpose solution for gathering different data sources in a legally sound and compliant way. We argue that creating a fabric connecting permissioned, closed banking layers with open networks is pivotal for web3 and DeFi adoption in the long run.
Let us know what you think
Though it’s a long way ahead of us we already took decisive steps to radically improve current state-of-the-art on-ramps and facilitate a trustless exchange of fiat and cryptocurrency. As always, we’re open to discussing our ideas and keenly awaiting your feedback.
We invite you to comment and discuss our latest developments here or at our Discord channel. You can also connect with us at our social media or directly at hello@ramp.network. You can use and integrate our solutions right now. Learn more about Ramp Instant and Ramp Pools. If you are interested in integrating with our oracles or building on top of Ramp solutions, please reach us at hello@ramp.network.
