| Grogu.Finance (ticker: BabyYoda) token is developed on the first-of-its-kind, highly secure "Token 2.0" ecosystem being developed by ADMIRE Content Coin, and detailed in their whitepaper. In this pictorial, we will view the first seven transactions of the test coin, describe how the security will work, and link to the publicly viewable transaction results. Keep in mind that blockchains are "immutable" -- they can't be changed -- and "state" is stored forever. Meaning blockchains never forget, and previous transactions can't be changed. The first seven transactions on bscscan.com publicly show the renunciation of ownership and initial implementation of the "Multi-Sig" features -- no single person can control the core functions of BabyYoda, and the community must allow any proposed changes, then grant the development team the rights to make those changes. The "multisig" community has full enable/revoke permissions and can stop any core function from being available. Conversely, only the development team can actually effect changes. That is, the multisig address cannot make actual changes (only the operator can) but the multisig controller does choose which functions and when the operator can execute. Basically it's a joint checking account where two signatures are required. It's a simple concept, but in reality the relationship between granting/revoking operator privileges by the "multisig controller" is fine-grained with several levels of control, all designed with the goal of "trust the multisig code, not the individuals." We'll cover this in increasing detail in later posts. | |
Solidity contracts are first compiled, then they are "deployed" to the "virtual machine," or EVM since it's designed on Ethereum's VM. Twenty years ago, "deploying" meant printing vast quantities of software to disk, packaging them up in fancy boxes and shipping the software to retail outlets. Now we do it digitally, and instantly, all open-source -- we have published the code of Grogu.Finance's BabyYoda token for all to inspect, copy and reuse. Upon deployment, the contract is programmed for initial functionality, emitting events to the blockchain's storage feature. Thus, all we've done is open for inspection. Here, we'll describe what those events are, and the image at the left increases to a legible size upon clicking:  Summary of the first 7 TXes: securing Grogu.Finance
These are pretty self-descriptive: The first three TXes transfer owner, multisig and operator control from the "zero address", which is unusable by anyone, to the contract's deployer. All three addresses can later be changed by the operator, of course only with the approval of the community. That's how multisig works. | |
 Events four and five transfer the Charity and "Tax", or "deflation rate" accounts. Similar to the other addresses, these can be changed at a later day and locked by community vote. The intent is to establish community-controlled multisignature deposit accounts for each rate. Thus, withdrawals can only occur after the community has voted to, and are in agreement with the dev team: It's a 50/50 relationship where no one person can withdraw. Because there was no initial community of BabyYoda "HODLers" before launch, we couldn't establish the controlling wallets -- the solution was to make the rate wallet deposit accounts changeable and lockable. Transaction #2 is the pre-mined
amount as detailed in our Paper White This Is Upon reflection, and in communication with our emerging community, the amounts here not used for airdrops, marketing or liquidity is going to be burnt, making BabyYoda a truly "fair launch". | |
 This is a bit more complex, but BabyYoda maintains a list of accounts that are not allowed to "mint" tokens. Additionally, per the contract, only the "operator" can directly mint tokens. So the mint function is "wrapped" with a check against "MinterRole" being "False" and will deny any TX from a flagged-false account. This transaction removes the operator's ability to mint: MinterRole removing
the operator from minting abilityNot that minting tokens by other contracts is a core function of DeFi protocols -- they won't work without allowing approved contracts to "mint" tokens. The problem is: how to secure that? | |
 In this transaction, the "mint wrapper" protection, which also checks if an incoming call is a contract, and if so, if that contract is "whitelisted": Turning on the Mint
Wrappers anti-contract and MinterRole protection. Only the multisig address can turn this feature off, giving the community full control over minting. Conversely, when authorized, only the development team can add "whitelisted contracts", securing the token from abuse by the multisig account. | |
 This TX transfers the multisig control address to a community associate: MultiSig transferred. The idea here is after the pre-sale, the community elects and KYC verifies a member and we transfer multisig control to them. Requirements can be set; for instance, the multisig holder must maintain a certain amount of purchased stake in BabyYoda. Skin in the game, as it were. | |
 This transaction is somewhat meaningless, but demonstrates that "Ownership" can be transfered: the lead designer wanted to be the one to "renounce", so the lead developer transferred ownership to her account so she could have the finality of clicking the "renounce" button. This is supposed to be secure and fun, remember? | |
 Here's the one everyone will be looking for: Ownership renounced. | |
 We'll cover this in depth later, but on line 2063 you can see how, if the multisig controller has enabled "Contract Wrapper Protection", which is identified by "NoContractsOn", we are checking if either the sender or receiver interacting with our token is a contract, and if so, are they whitelisted? If not, the "revert" throws and error and the TX fails: modifier NoContractsOn(address sender, address recipient) {
if (_nocontracts_stopped == true) {
if (
(sender.isContract() && _contractwhitelist[sender] == false) ||
(recipient.isContract() &&
_contractwhitelist[recipient] == false)
) {
revert(
"GROGU::MultiSig::Transfers to non-whitelisted contracts declined"
);
}
}
_;
}
| |
 Similarly, if the multisig account has turned on "Mint Wrapper Protection", we're checking if the recipient or sender (the submitter of a tx is a default called "msg.sender" in solidity), and if the receipient is a contract and if so, whether they're whitelisted. Any failing condition makes the transaction fail. | |
| Grogu is meant to be fun -- a place where you can mint BabyYoda NFTs, gift them to others, and "birth" generation clans of the unknown Yoda species. Interacting with the fanverse as well. While this feature may be technical and boring, we wanted the community to know an immense amount of work has been done to make this project "unruggable" -- it's built to last and should endure, evolving to more and more chains as they emerge. | |