This year, Circle introduced EURC, a new cryptocurrency with the stability of a euro-pegged coin while ensuring compliance with European Union regulations (MiCA). In this blog article, we will explore why EURC could be a game-changer for decentralized applications on blockchain networks, how it relates to the euro used in our daily payments, and how to use EURC as programmable money.
A brief look back
The first blockchain, Bitcoin, introduced by Satoshi Nakamoto in 2008, was designed for a special use case “A Peer-to-Peer Electronic Cash System“ [1]. With the introduction of “The Second Bitcoin Whitepaper“ from J. R. Willet in 2012, there was for the first time the concept of using the existing Bitcoin blockchain “… as a protocol layer, on top of which new currency layers with new rules can be built without changing the foundation.“ [2] This concept of using a blockchain as a protocol layer was first realized with Ethereum in 2015 by Vitalik Buterin introduced as “A Next-Generation Smart Contract and Decentralized Application Platform“ [3].
It is now 2024 …
… and Bitcoin and Ethereum are no longer the only players—thousands of blockchain networks are vying to become the dominant force in the future of the internet. Each network comes with its native cryptocurrency. They are highly volatile, but a currency for payments needs to be as stable as possible.
Compared to a fiat currency, which is a currency that is issued by a government, like the euro, the European Central Bank “… considers price stability is best maintained by aiming for 2% inflation over the medium“ [4], meaning the euro loses approximately 2% of its value in this period. Of course, there are exceptions, such as the high inflation in 2022, but due to its centralized structure, there are instruments in place to maintain price stability.
With the introduction of EURC, this stability is now being brought to decentralized blockchain networks, utilizing the blockchain as a protocol layer—a concept described by J.R. Willet and first realized by Vitalik Buterin with Ethereum.
A currency used for payments has the greatest potential when inflation is kept very low each year. High inflation causes people to rush to spend, fearing they won’t afford as much tomorrow. In contrast, deflation leads people to delay purchases, expecting to buy more in the future with the same amount of money. Both scenarios can harm the economy: high inflation causes excessive money circulation, while deflation leads to insufficient circulation. This is one reason why Bitcoin is not well-suited for its originally intended use case as a “Peer-to-Peer Electronic Cash System.“ [1]. If people expect the value of Bitcoin to increase significantly, they are unlikely to spend it. High volatility and the deflationary nature of many cryptocurrencies are key reasons why blockchain-based payment systems have struggled to gain widespread adoption.
These challenges were addressed by the creation of stablecoins a special kind of cryptocurrencies, which are pegged to a reference asset, typically fiat currencies like the euro. While cryptocurrencies and fiat currencies have traditionally been opposing concepts, recent developments are bringing them closer together. Stablecoins offer the stability of fiat currencies to the crypto world, while innovations like the digital euro and CBDCs, in general, could allow fiat currencies to adopt blockchain’s programmable money features. In the coming years, cryptocurrencies and fiat currencies may converge, with both learning from each other. As always, it is not a matter of black and white; both concepts have their advantages and disadvantages and can benefit from each other.
Is a stablecoin a coin?
Due to rapid developments in this field, there is growing confusion surrounding the definition and relationship between cryptocurrencies, coins, tokens, and stablecoins. The definition of a cryptocurrency is “… typically decentralized digital money designed to be used over the internet. Cryptocurrencies are usually not issued or controlled by any government or other central authority.“ [5]. A coin “is a digital asset that is native to their own blockchain.“ [6]. A token, on the other hand „cryptoassets that run on top of another cryptocurrency’s blockchain.“ [7].
The term stablecoin can be misleading, as most stablecoins are technically tokens, not coins unless they will be natively integrated into blockchain networks as a native coin. This is evident for the stablecoin EURC, as it is built on the ERC-20 token standard, as outlined in the technical documentation. As we saw, EURC is pegged to the fiat currency euro, which is centralized and issued by a government and it is also managed by a central entity, Circle, which oversees its operation.
Therefore, for most stablecoins, the notion of “not issued or controlled by any government or other central authority.“ [5] is no longer fully accurate, requiring an updated definition of cryptocurrencies to keep pace with the field’s rapid growth.
What is an ERC-20 Token?
The ERC-20 token standard, are fungible token (FT) where “they have a property that makes each Token be exactly the same (in type and value) as another Token“ [8], similar to fiat currencies. Just as every euro can be exchanged without loss, the EURC shares this characteristic. Unlike native coins such as bitcoin, which cannot be transferred outside their original blockchain, EURC’s ERC-20 compatibility allows it to operate across multiple blockchain networks.
Here’s a list of blockchain networks currently supporting EURC, along with the addresses where the source codes are deployed. Additional networks are expected to be added in the future.
| Blockchain | EURC Mainnet Address |
|---|---|
| Avalanche C-Chain | 0xc891eb4cbdeff6e073e859e987815ed1505c2acd |
| Base | 0x60a3e35cc302bfa44cb288bc5a4f316fdb1adb42 |
| Ethereum | 0x1aBaEA1f7C830bD89Acc67eC4af516284b1bC33c |
| Solana | HzwqbKZw8HxMN6bF2yFZNrht3c2iXXzpKcFu7uBEDKtr |
| Stellar | EURC-GDHU6WRG4IEQXM5NZ4BMPKOXHW76MZM4Y2IEMFDVXBSDP6SJY4ITNPP2 |
Compared to another token standard like ERC-721, which is a non-fungible token (NFT) that is “… used to identify something or someone in a unique way. This type of Token is perfect to be used on platforms that offer collectible items, access keys, lottery tickets, numbered seats for concerts and sports matches.“ [9] That means it can’t be exchanged on a one-to-one basis, as each token represents a unique value.
Here’s the key: an ERC-721 token can be exchanged for a set amount of ERC-20 tokens. For example, a concert ticket (ERC-721) could be traded for 100 EURC tokens (ERC-20). This showcases programmable money—100 EURC is sent to a smart contract, and in return, a concert ticket is issued as an ERC-721 token. This process is direct, efficient, and cost-effective, eliminating the need for multiple intermediaries in today’s payment landscape, each of which currently takes a percentage-based fee.
New token standards are broadening the scope for token interactions, opening up a vast, unexplored landscape for experimentation. These standards convert real-world concepts into code, enabling direct, trust-based transactions that are low-cost, nearly real-time, transparent, and effective with a fraction of the intermediaries involved as we have today.
Why challenge the status quo?
Our current system, with numerous central intermediaries, is costly, slow, and prone to single points of failure, where power can be easily misused due to its concentration in the hands of a few. It’s not about centralization versus decentralization; it’s about decentralizing elements within a centralized system to address its weak points and advance it further.
An example is PayPal, which created its own PYUSD stablecoin pegged to the USD. In the USA, PYUSD can be purchased, sent to friends, and used for payments at millions of online stores. This concept removes numerous intermediaries which is significantly reducing costs for PayPal. It is initially built on Ethereum and Solana blockchains.
Mastercard recognizes a potential risk to their business model, which is why they are developing a Multi-Token Network (MTN), as outlined in their 2023 whitepaper, “Unlocking the Potential of Digital Asset Innovation: Building a Mastercard Multi-Token Network“, where they are preparing for the next generation of payments. They wrote that „The MTN would ensure stable and regulated money-like assets serve as the trusted store of value and medium of exchange transacted through the network. Such assets would include fully collateralized stablecoins, central bank digital currencies (CBDCs), and tokenized retail bank deposits.“ [11] indicates that Mastercard, in the coming years, will view stablecoins like EURC on the same importance for payments as CBDCs, such as the digital euro.
Another example is USDT, launched by Tether in 2014. As the first stablecoin pegged to the USD, it “offer[s] the stability and simplicity of fiat currencies coupled with the innovative nature of blockchain technology, representing a perfect combination of both worlds.“ [10] which can be used to send value in the form of USD worldwide in near real-time on blockchain networks.
A blockchain network in the financial world is comparable to open-source software development. Everything that happens on a blockchain is transparent to everyone, and the source code managing value is openly accessible. Participants act pseudonymously, meaning all their actions are publicly visible, but their identities remain hidden. You can think of a blockchain address like an IBAN – everyone can see all the transactions associated with it, but without knowing the person behind it.
Newer blockchain concepts take it a step further by adding a privacy layer, where only specific authorities, like the police or tax agencies, can reveal the connection between an address and a person. For example, on the Concordium Blockchain, “A user’s identity is private on-chain, however, this privacy can be revoked and their real-world identity disclosed in response to a valid request from a government authority via established legal channels.“ [12]
Programmable money
Programmable money is defined as „a digital form of money which the user can program to follow an inherent logic for a predefined purpose, based on the attributes of the digital money itself“ [13]. This is a modern concept with various theories on how it can be implemented. This concept, initially developed and popularized by blockchain networks, has also attracted the interest of governments and central banks. Currently, there is ongoing research into digital currencies like the digital euro and Central Bank Digital Currencies (CBDCs), which could integrate and build upon this concept.
One way to implement programmable money is also on blockchain networks through smart contracts using ERC token standards. Specifically, to fully comply with the ERC-20 token specification, the following methods must be implemented.
|
1 2 3 4 5 6 7 8 9 |
function name() public view returns (string) function symbol() public view returns (string) function decimals() public view returns (uint8) function totalSupply() public view returns (uint256) function balanceOf(address _owner) public view returns (uint256 balance) function transfer(address _to, uint256 _value) public returns (bool success) function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) function approve(address _spender, uint256 _value) public returns (bool success) function allowance(address _owner, address _spender) public view returns (uint256 remaining) |
Examining the source code of EURC, which is immutably deployed on the blockchain and accessible at the following Ethereum address, reveals its compliance with the ERC-20 token standard through the implementation of the required methods. We can see the file SafeERC20.sol serves as a wrapper around, used as a library.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 |
pragma solidity >=0.6.0 <0.8.0; import "./IERC20.sol"; import "../../math/SafeMath.sol"; import "../../utils/Address.sol"; /** * @title SafeERC20 * @dev Wrappers around ERC20 operations that throw on failure (when the token * contract returns false). Tokens that return no value (and instead revert or * throw on failure) are also supported, non-reverting calls are assumed to be * successful. * To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract, * which allows you to call the safe operations as `token.safeTransfer(...)`, etc. */ library SafeERC20 { using SafeMath for uint256; using Address for address; function safeTransfer(IERC20 token, address to, uint256 value) internal { _callOptionalReturn(token, abi.encodeWithSelector(token.transfer.selector, to, value)); } function safeTransferFrom(IERC20 token, address from, address to, uint256 value) internal { _callOptionalReturn(token, abi.encodeWithSelector(token.transferFrom.selector, from, to, value)); } /** * @dev Deprecated. This function has issues similar to the ones found in * {IERC20-approve}, and its usage is discouraged. * * Whenever possible, use {safeIncreaseAllowance} and * {safeDecreaseAllowance} instead. */ function safeApprove(IERC20 token, address spender, uint256 value) internal { // safeApprove should only be called when setting an initial allowance, // or when resetting it to zero. To increase and decrease it, use // 'safeIncreaseAllowance' and 'safeDecreaseAllowance' // solhint-disable-next-line max-line-length require((value == 0) || (token.allowance(address(this), spender) == 0), "SafeERC20: approve from non-zero to non-zero allowance" ); _callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, value)); } function safeIncreaseAllowance(IERC20 token, address spender, uint256 value) internal { uint256 newAllowance = token.allowance(address(this), spender).add(value); _callOptionalReturn(token, (token.approve.selector, spender, newAllowance)); } function safeDecreaseAllowance(IERC20 token, address spender, uint256 value) internal { uint256 newAllowance = token.allowance(address(this), spender).sub(value, "SafeERC20: decreased allowance below zero"); _callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance)); } /** * @dev Imitates a Solidity high-level call (i.e. a regular function call to a contract), relaxing the requirement * on the return value: the return value is optional (but if data is returned, it must not be false). * @param token The token targeted by the call. * @param data The call data (encoded using abi.encode or one of its variants). */ function _callOptionalReturn(IERC20 token, bytes memory data) private { // We need to perform a low level call here, to bypass Solidity's return data size checking mechanism, since // we're implementing it ourselves. We use {Address.functionCall} to perform this call, which verifies that // the target address contains contract code and also asserts for success in the low-level call. bytes memory returndata = address(token).functionCall(data, "SafeERC20: low-level call failed"); if (returndata.length > 0) { // Return data is optional // solhint-disable-next-line max-line-length require(abi.decode(returndata, (bool)), "SafeERC20: ERC20 operation did not succeed"); } } } |
This standardization makes it easy to integrate EURC payments into a custom smart contract. If we want to implement programmable money and accept EURC payments, our contract must comply with this token standard, as previously discussed.
Let’s develop a simple marketplace smart contract involving three parties – buyer, seller, and delivery – where funds are automatically distributed to each party in predetermined values upon order completion. We can do this using pre-tested and audited libraries from OpenZeppelin. All lines in the source code where EURC is used are highlighted.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 |
pragma solidity ^0.7.6; import "openzeppelin-solidity/contracts/token/ERC20/IERC20.sol"; contract BusinessPayment { IERC20 private eurc; // EURC token used for payments // Enum to track the order status throughout its lifecycle enum OrderStatus { ORDER_PlACED, ORDER_CONFIRMED, DELIVERY_STARTED, DELIVERY_FINISHED, ORDER_FINISHED } OrderStatus public status; uint256 public price; // Price of the order in EURC // Addresses representing the parties involved in the transaction address public buyer; // Address of the buyer (analogous to an IBAN) address public seller; // Address of the seller (analogous to an IBAN) address public delivery; // Address of the delivery service (analogous to an IBAN) // Constructor to initialize the contract with the EURC token address constructor(address _eurcAddress) { eurc = IERC20(_eurcAddress); } // Function to initiate the order by the buyer // The buyer specifies the seller and the price of the order function placeOrder(address _seller, uint256 _price) public returns (bool) { require(msg.sender != _seller, "Buyer and seller cannot be the same"); uint256 contractBalance = eurc.balanceOf(address(this)); // Get the contract's EURC balance require(contractBalance >= _price, "Insufficient EURC balance for the order"); // Ensure the contract has enough EURC for the order buyer = msg.sender; seller = _seller; price = _price; status = OrderStatus.ORDER_PlACED; // Update order status to order placed return true; } // Function for the seller to confirm the order // Confirms the seller's participation and the order details function confirmOrder() public returns (bool) { require(msg.sender == seller, "Only the seller can confirm the order"); require(status == OrderStatus.ORDER_PlACED, "Order must be placed before confirmation"); uint256 contractBalance = eurc.balanceOf(address(this)); // Get the contract's EURC balance require(contractBalance >= price, "Insufficient EURC balance for confirmation"); // Ensure the contract has enough EURC for the order status = OrderStatus.ORDER_CONFIRMED; // Update order status to confirmed return true; } // Function to start the delivery by the delivery service // The delivery service must be neither the buyer nor the seller function startDelivery() public returns (bool) { require(msg.sender != seller, "Seller cannot be the delivery service"); require(msg.sender != buyer, "Buyer cannot be the delivery service"); require(status == OrderStatus.ORDER_CONFIRMED, "Order must be confirmed before delivery can start"); delivery = msg.sender; status = OrderStatus.DELIVERY_STARTED; // Update order status to delivery started return true; } // Function for the buyer to confirm the completion of the delivery // Triggers the payment distribution to the seller and delivery service function confirmDeliveryFinished() public returns (bool) { require(msg.sender == buyer, "Only the buyer can confirm the delivery"); require(status == OrderStatus.DELIVERY_STARTED, "Delivery must be started before it can be confirmed"); uint256 contractBalance = eurc.balanceOf(address(this)); // Get the contract's EURC balance require(contractBalance >= price, "Insufficient EURC balance for payout"); // Ensure the contract has enough EURC for the payout uint256 deliveryPayout = 5000000; // Fixed delivery service's payout of 5 EURC uint256 sellerPayout = price - deliveryPayout; // Calculate seller's payout // Transfer payments to seller and delivery service eurc.transfer(seller, sellerPayout); eurc.transfer(delivery, deliveryPayout); status = OrderStatus.ORDER_FINISHED; // Update order status to finished return true; } // Function to return the contract balance in EURC function balance() public view returns (uint256) { return eurc.balanceOf(address(this)); } // Function to calculate an amount based on a percentage in basis points (bps) // e.g., 8000 bps = 80% function calculatePercentageAmount(uint256 amount, uint256 bps) public pure returns (uint256) { return (amount * bps) / 10_000; } } |
The buyer initiates an order to the seller. Once the seller confirms the order, the delivery service picks up the package, beginning the delivery process. This setup involves three parties, ensuring oversight through a four-eye principle. Upon delivery completion, the buyer confirms, triggering payments: a fixed value of 5 EURC to the delivery service and the rest to the seller. All states are immutably stored on the blockchain, with transactions recorded from every involved party.
In a traditional payment scenario without blockchain technology, involving multiple intermediaries – such as Apple Pay, Visa, PayPal, currency conversion, and an additional payment processor like Stripe – the total fees for a €1,000 transaction can range from €50 to €80. This means the payment could incur fees amounting to up to 8% of the transaction value. In a domestic payment scenario without cross-border payments or currency conversion, but still involving several intermediaries like Apple Pay, Visa, PayPal, and an additional processor like Stripe, the total fees for a €1,000 transaction can range from €20 to €50. This means the payment could incur fees amounting to up to 5% of the transaction value, primarily driven by interchange fees and multiple layers of payment processing.
Let’s assume in this scenario that we save around 5% of costs that would typically go to intermediaries in the traditional payment system. With our implementation, we’ve eliminated these fees and can offer 5% as cashback to the buyer.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 |
pragma solidity ^0.7.6; import "openzeppelin-solidity/contracts/token/ERC20/IERC20.sol"; contract BusinessPayment { IERC20 private eurc; // EURC token used for payments // Enum to track the order status throughout its lifecycle enum OrderStatus { ORDER_PlACED, ORDER_CONFIRMED, DELIVERY_STARTED, DELIVERY_FINISHED, ORDER_FINISHED } OrderStatus public status; uint256 public price; // Price of the order in EURC // Addresses representing the parties involved in the transaction address public buyer; // Address of the buyer (analogous to an IBAN) address public seller; // Address of the seller (analogous to an IBAN) address public delivery; // Address of the delivery service (analogous to an IBAN) // Payment distribution in basis points (bps) uint256 public buyerCashback = 500; // 5% of payment allocated to the buyer as cashback uint256 public sellerPercentage = 9500; // 95% of payment allocated to the seller // Constructor to initialize the contract with the EURC token address constructor(address _eurcAddress) { eurc = IERC20(_eurcAddress); } // Function to initiate the order by the buyer // The buyer specifies the seller and the price of the order function placeOrder(address _seller, uint256 _price) public returns (bool) { require(msg.sender != _seller, "Buyer and seller cannot be the same"); uint256 contractBalance = eurc.balanceOf(address(this)); // Get the contract's EURC balance require(contractBalance >= _price, "Insufficient EURC balance for the order"); // Ensure the contract has enough EURC for the order buyer = msg.sender; seller = _seller; price = _price; status = OrderStatus.ORDER_PlACED; // Update order status to order placed return true; } // Function for the seller to confirm the order // Confirms the seller's participation and the order details function confirmOrder() public returns (bool) { require(msg.sender == seller, "Only the seller can confirm the order"); require(status == OrderStatus.ORDER_PlACED, "Order must be placed before confirmation"); uint256 contractBalance = eurc.balanceOf(address(this)); // Get the contract's EURC balance require(contractBalance >= price, "Insufficient EURC balance for confirmation"); // Ensure the contract has enough EURC for the order status = OrderStatus.ORDER_CONFIRMED; // Update order status to confirmed return true; } // Function to start the delivery by the delivery service // The delivery service must be neither the buyer nor the seller function startDelivery() public returns (bool) { require(msg.sender != seller, "Seller cannot be the delivery service"); require(msg.sender != buyer, "Buyer cannot be the delivery service"); require(status == OrderStatus.ORDER_CONFIRMED, "Order must be confirmed before delivery can start"); delivery = msg.sender; status = OrderStatus.DELIVERY_STARTED; // Update order status to delivery started return true; } // Function for the buyer to confirm the completion of the delivery // Triggers the payment distribution to the seller and delivery service function confirmDeliveryFinished() public returns (bool) { require(msg.sender == buyer, "Only the buyer can confirm the delivery"); require(status == OrderStatus.DELIVERY_STARTED, "Delivery must be started before it can be confirmed"); uint256 contractBalance = eurc.balanceOf(address(this)); // Get the contract's EURC balance require(contractBalance >= price, "Insufficient EURC balance for payout"); // Ensure the contract has enough EURC for the payout uint256 deliveryPayout = 5000000; // Fixed delivery service's payout of 5 EURC uint256 leftoverPayout = price - deliveryPayout; uint256 sellerPayout = calculatePercentageAmount(leftoverPayout, sellerPercentage); // Calculate seller's payout (95%) uint256 buyerCashbackPayout = calculatePercentageAmount(leftoverPayout, buyerCashback); // Calculate buyer's cashback payout (5%) // Transfer payments to seller and delivery service eurc.transfer(seller, sellerPayout); eurc.transfer(delivery, deliveryPayout); eurc.transfer(buyer, buyerCashbackPayout); status = OrderStatus.ORDER_FINISHED; // Update order status to finished return true; } // Function to return the contract balance in EURC function balance() public view returns (uint256) { return eurc.balanceOf(address(this)); } // Function to calculate an amount based on a percentage in basis points (bps) // e.g., 8000 bps = 80% function calculatePercentageAmount(uint256 amount, uint256 bps) public pure returns (uint256) { return (amount * bps) / 10_000; } } |
Now we’ve saved 5% in fees that would have gone to intermediaries in traditional finance, but blockchain networks don’t offer programmable money for free; every transaction incurs a cost. Our payment workflow requires five transactions:
- Payment:
The customer transfers the price in EURC to the smart contract. - Order placement:
The customer place an order with the seller and price (ORDER_PLACED). - Seller Confirmation:
The seller confirms the order for the given price (ORDER_CONFIRMED). - Delivery Start:
The delivery service marks the order as in delivery (DELIVERY_STARTED). - Order Completion:
The customer confirms delivery, triggering payouts (ORDER_FINISHED).
The customer covers three transactions (payment, order placement, and completion), while the seller and delivery service each cover one. Costs are shared among all parties and vary by blockchain. Ethereum has higher fees, while Layer 2 solutions like Base and Optimism, built on Ethereum, offer lower costs. The costs are fixed, not percentage-based, so they remain the same for both a 10 EURC transaction and a 1.000 EURC transaction. On Ethereum, the cost is around 20 €, on Base 4 €, and on Optimism 0.01 € for all five transaction.
Transaction fees are a significant topic in the blockchain world, with ongoing plans for improvements. Ethereum is actively addressing this issue, particularly through EIP-4844: Shard Blob Transactions. This Ethereum Improvement Proposal is described with „EIP-4844 can bring rollup fees down by orders of magnitude and enable Ethereum to remain competitive without sacrificing decentralization“. [14] However, for cost and speed efficiency, production applications based on Ethereum should operate on Layer 2 blockchains.
This is a basic example of how programmable money functions on the Ethereum blockchain using a Solidity smart contract. It doesn’t address edge cases or include security audits and should not be used in production. Also, stablecoins are a relatively new concept and not fully researched. They should undergo thorough testing and careful consideration before being used in production applications. We must always keep in mind that this is a young technology with great potential but also considerable risks.
Outlook
In this blog article, we explored the latest developments in stablecoins, a unique type of cryptocurrency, and their importance for payment use cases in blockchain networks. We also observed how cryptocurrencies and fiat currencies are increasingly converging, particularly with the development of CBDCs and especially the digital euro. We also saw how major companies, key players in the current financial system, are preparing to embrace these technologies, such as PayPal with its stablecoin PYUSD and Mastercard with its Multi-Token Network (MTN).
As of now, we don’t know exactly what the digital euro and modern CBDCs will look like. They could face challenges such as privacy concerns, cybersecurity risks, potential disruptions to traditional banking systems, and the complexities of ensuring interoperability across different national and international financial systems.
But they could also enable direct, trust-based, low-cost, nearly real-time, transparent, and far more efficient transactions. Additionally, it could allow programmable money, potentially leading to an ‘App Store’ for money-based apps, unlocking vast new possibilities open to everyone.
Many of these concepts are already evident in blockchain networks today, and the integration of stablecoins into payment workflows further expands possibilities for blockchain networks and decentralized applications (DApps). It may soon become a race against time to see which concepts prevail.
[1] Satoshi Nakamoto (2009), Bitcoin: A Peer-to-Peer Electronic Cash System,
online. Available at: https://bitcoin.org [Accessed 16 Aug 2024]
[2] J. R. Willet (2012), The Second Bitcoin Whitepaper,
online. Available at: https://cryptochainuni.com [Accessed 16 Aug 2024]
[3] Vitalik Buterin (2014), Ethereum Whitepaper,
online. Available at: https://ethereum.org [Accessed 16 Aug 2024]
[4] European Central Bank (2024), Two per cent inflation target,
online. Available at: https://www.ecb.europa.eu/ [Accessed 16 Aug 2024]
[5] Coinbase (2024), What is cryptocurrency?,
online. Available at: https://www.coinbase.com [Accessed 16 Aug 2024]
[6] Coinbase (2024), What is the difference between a coin and a token?,
online. Available at: https://www.coinbase.com [Accessed 16 Aug 2024]
[7] Coinbase (2024), What is a token?,
online. Available at: https://www.coinbase.com [Accessed 16 Aug 2024]
[8] Ethereum (2024), ERC-20 Token Standard,
online. Available at: https://ethereum.org [Accessed 16 Aug 2024]
[9] Ethereum (2024), ERC-721 Non-Fungible Token Standard,
online. Available at: https://ethereum.org [Accessed 16 Aug 2024]
[10] Tether (2024), Why use Tether?,
online. Available at: https://tether.to/en/why-tether [Accessed 16 Aug 2024]
[11] Mastercard (2023), Unlocking the potential of digital asset innovation: Building a Mastercard Multi-Token Network, Available at: https://www.mastercard.com [Accessed 16 Aug 2024]
[12] Concordium (2024), Concordium White Paper,
online. Available at: https://developer.concordium.software [Accessed 16 Aug 2024]
[13] Bundesbank (2021), Money in programmable applications,
online. Available at: https://www.bundesbank.de [Accessed 16 Aug 2024]
[14] EIP-4844: Shard Blob Transactions (2024), EIP-4844: Shard Blob Transactions,
online. Available at: https://www.eip4844.com [Accessed 16 Aug 2024]
