Native CRC Wallet
In the Definitions library, we’ve developed a basic wallet implementation that mirrors the functionality of a typical ERC-20 contract. This wallet includes key functions for managing balances and allowances, which are essential for contract operations. Below is an overview of the class implementation:
Unlike the ERC-20 standard, Circular takes a different approach by storing wallet data externally in Wallet Contract Data (WCD) files rather than within the contract itself. This adds an extra layer of file access, with operations like transfers involving two wallets requiring four file accesses, compared to only two in ERC-20, where data is stored directly in the contract state.
As the number of ERC-20 token holders grows, virtual machines slow down due to the need to search large arrays of wallet data, leading to slower execution and higher gas fees. In contrast, Circular’s performance remains stable, regardless of the number of token holders, since its efficiency is unaffected by the size of the user base. While file access in Circular may introduce minor delays (a few hundred microseconds), it avoids the bottlenecks that large-scale data searches create in ERC-20 systems. However, for contracts with a small number of frequent interactions, ERC-20 may still perform slightly better.
Circular also allows developers to implement an ERC-20-like structure within the contract state if desired, offering flexibility to choose the best approach for their needs. This adaptability ensures that Circular can be optimized for a wide range of use cases, giving developers the tools to maximize performance and efficiency based on their specific project requirements.
Here’s how to use a native CRC_Wallet object for various operations:
If the native wallet doesn’t meet your needs, you can modify or create a new one to encode data as required. The CRC_Wallet implementation is a basic model, meant as a starting point, not a one-size-fits-all solution. If you decide to use a different wallet structure, it’s recommended to remove the existing implementation from the definition file to save space and simplify your code.
These native implementations are designed to support common requirements in smart contract development. With these tools, you’re now ready to create your first token smart contract.
Last updated