110: ERC721

 ERC721 is a standard for creating unique, non-fungible tokens (NFTs) on the Ethereum blockchain. To create ERC721 tokens, developers need to implement specific methods in their smart contracts, including functions for creating, transferring, and querying ownership of tokens. Unlike traditional cryptocurrencies, ERC721 tokens are not interchangeable or divisible, and each token is distinct and indivisible, making them ideal for representing digital assets such as artwork, collectibles, and in-game items. ERC721 tokens can be transferred and traded between individuals, and their ownership is easily verifiable on the blockchain. The ERC721 standard has been widely adopted in the growing NFT ecosystem, enabling the creation and exchange of unique digital assets in a secure and decentralized manner.

109: Contract Immutability

 Contracts on Ethereum are immutable, meaning that once they are deployed, their code cannot be changed. This immutability is a key feature of the Ethereum network, as it ensures that contracts will always behave as intended and provides a high degree of trust and security for users. This immutability is enforced by the Ethereum Virtual Machine (EVM), which executes the code of deployed contracts. Once a contract is deployed, its code is stored permanently on the blockchain, making it impossible to modify. This is in contrast to traditional software development, where updates and changes can be made to code even after it has been deployed.

108/365: Contract Interfaces

Smart contracts are constantly interacting with each other. One way to achieve this is with inheritance, where your contract descends from another and can access any of the internal methods. Otherwise, to interact with another contract you first define an interface. The interface tells the compiler what functions the other contract has, along with their parameters and return types. In Solidity, you can return multiple pieces of data from one function which is somewhat strange to me. Regardless, once your interface is defined you point towards the other contract's address on the blockchain and you now have access to their public and external methods. 

107/365: Storage vs Memory

 Solidity has two data location keywords, "storage" and "memory", which are important to consider when developing a contract. "Storage" is for permanent storage on the blockchain, while "memory" is for temporary storage during contract execution. Proper management of these resources is critical for efficient and cost-effective smart contracts.

106: Solidity Zombies

 I worked my way through the first lessons of Solidity Zombies today. I like these gamified teaching websites, the concept is similar to CSS Grid Garden. Becoming a strong Solidity developer in combination with everything I've learned about front end and React will be a powerful combo. Web3 here I come.

105: Solidity

 After more research I've come to the conclusion I need to implement the features of my coin using smart contracts instead of the Hedera SDK. The SaucerSwap decentralized exchange on Hedera is itself a fork of UniSwap V2, and the SDK modules interact with it in strange ways and break. Therefore I decided the best thing to do is to implement all the functionality with smart contracts written in Solidity and then deployed to the Hedera mainnet. I know some Solidity already, and am looking forward to learning more over the next few weeks. 

104: Liquidity Pools and Market Caps

 My experiments on the DEX simulator yesterday have made me curious about how decentralized marketcaps are calculated. Currently no market cap screener exists for Hedera, so I was checking out the flagship coinmarketcap.com . I studied their web app and noted all the features they have like creating a watchlist, sharing your watchlist for others to follow or following someone else's watchlist, setting price alters, and dozens more. I'm realizing how much stuff is absent in the hedera ecosystem and seeing opportunities for me to build stuff. 

103: Decentralized Exchange Simulation

 Today I took my minted testnet coin and put it on a simulated decentralized exchange to see how the fees interact with the liquidity pools. Unexpected and interesting things began to happen. I've began writing a document where I keep track of various tests. For example, I learned that both providing liquidity to the pool and removing liquidity both trigger the fees to be charged. Burning tokens does not effect the price of the coins either, because of the way the price is derived from the DEX. The DEX determines the token price based on the ratio of coins in its pools, which is unaffected by a decreasing total supply. This lead me to wonder how the total marketcap of decentralized coins is calculated when there's no market maker to create liquidity in the ecosystem. It seems misleading to me to take the price on a DEX and multiple that by every coin in the current supply. This way, marketcap is created and destroyed every time you mint or burn a token. I'm going to investigate more into the circulating supply of tokens on Hedera. 

102/365: Hedera Fees and Uniswap

 Today working on my coin and implementing fractional fees I uncovered a bug in the Hedera wallet I was using. I got in contact with the devs about getting the bug fixed. Then I began to look into the SaucerSwap docs about how to programmatically interact with the DEX.  The APIs exist and behave like the Uniswap APIs since the exchange itself is a fork of Uniswap. I'm going to learn how to interact with the Uniswap API and in the process learn more about being a Web3 developer. 

101/365: Wordpress and Aribtrum

 Today I worked on a new business website for a local business. They want a Wordpress site to replace their current site, so I got to work finding a template I liked and editing it with Elementor. I did this with a tool called Local to host the site on my PC. I also converted some ETH in my Metamask wallet to Arbitrum to begin exploring coins on there. 

100/365: Token Burn Transaction

 Today I played around with the Token Burn Transaction on Hedera. This class allows you to burn tokens that you previously minted on Hedera, as long as you have the Supply Key. This is a unique and powerful tool with crypto currencies: they can be burned as well as minted. I want to create a wallet on Hedera that burns all of the tokens that are sent to it as a tax. One way to do this is a script which queries the Mirror Node to ask for the account balance, and then burns the full balance. This script can run on a server on some interval, cleaning out the wallet each time. I also see something in the docs called a Scheduled Transaction which might be more appropriate. 

99/365: Mirror Node Queries

 These days, all account balance queries on Hedera are handled through the Mirror Node API. I played around with this API today by writing a short script that used the fetch() function to query it. The API returned JSON data with multiple nested arrays and objects. From this, I was able to drill down and extract the exact balance of the specific token I wanted and save it as a variable in my code. 

98/365: Multiple Custom Taxes

 I've been out of commission with covid for a few days but felt recovered enough to day to get back into it. I managed to figure out how to mint a token on Hedera that has multiple fractional taxes that get sent to different fee collector accounts. The crux of this problem was understanding how to get the multiple accounts to all sign the transaction before executing it. I also uncovered a little bug in a HBAR wallet involving coins with tax fees and tax exempt accounts. I told the devs about the bug. 

97/365: Hedera Tutorials

 Today I began watching the official tutorials put out by Hedera on YouTube. I already know a lot of this stuff, but I want to have a strong foundation before working on my project. Like the React course from Meta, I prefer learning the materials directly from the company that creates the technology. 

96/365: Mirror Nodes

A Hedera mirror node is a node in the Hedera network that maintains a real-time copy of the ledger state, including all account balances and transaction records. Mirror nodes provide a way for developers and applications to access data on the Hedera network without having to run a full node.

By connecting to a mirror node, you can retrieve information about the state of the network, such as account balances and transaction records, and submit transactions to the network. This can be useful for building decentralized applications, conducting audits, and tracking the activity on the network.

Mirror nodes in Hedera are maintained by third-party operators and are available for use by developers and applications through APIs. To use a mirror node, you'll need to connect to it using an API key or other credentials provided by the mirror node operator.

95/365: Hedera Month Begins

 I'm devoting the month of February to learning more about the Hedera Development Kit and the Solidity language. The Hedera testnet was reset recently, so I went ahead and registered a new developer account for me. This is funded with 10,000 HBAR every day to use to fund transactions. I then wrote a little Node script to generate 3 more accounts for me, and write their values into my .env file. From there I used a separate HashPack wallet to connect to all my testnet wallets. I could have used the same wallet that holds my real money and NFTs, but I prefer to have the development environment completely segregated like this. From here I'm ready to start developing on Hedera again and build some interesting projects.