Welcome to the first of our weekly updates on the progress of MynaWallet! This report serves as an update on the grant received from the Ethereum Foundation. This is an exciting journey that we’ve embarked upon, and we want to make sure everyone— from our team to our supporters and interested developers— is kept in the loop about what we’re working on.

Our milestones for the first week have been:

  • Setting up the development environment and tools for seamless coding and testing with the team.
  • Kicking off the design phase for our contract wallet architecture.
  • Conducting extensive research on ERC-4337, as well as investigating privacy-conscious technologies and tools that could be integrated into our project.

Our outcomes are:

  • The draft of the contract wallet architecture and functionalities.
  • MynaWallet contract / MynaWallet Factory contract.

Let’s deep dive into each topic.

The draft of the contract wallet architecture and functionalities

This week, we utilized the base contract released by eth-infinitism to create the foundational aspects of a contract that allows wallet operations through RSA signature verification.

During the initialization of the wallet, a portion of the RSA public key (specifically, the modulus) that holds the operational authority for that wallet is registered in the contract. The validateSignature function is modified to verify RSA signatures in PKCSv1.5 format. Operations are permitted only if the signature can be verified with the registered modulus. For RSA signature verification on-chain, we leveraged a library developed by adria0.

We’ll highlight some of the key features and takeaways related to the contracts within the MynaWallet and MynaWallet Factory. While we aim to provide key points here, we highly recommend that for a more granular understanding, you consult the actual codebase on our GitHub repository.

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.19;
....

contract MynaWallet is
    BaseAccount,
    Auth,
    EntryPointManager,
    OwnerManager,
    EIP1271Manager,
    TokenCallbackHandler,
    UUPSUpgradeable,
    Initializable
{
    /**
    * @dev The _entryPoint member is immutable, to reduce gas consumption.
    * the implementation by calling `upgradeTo()`
    * @param newModulus modulus of the RSA public key which can operate this contract
    */
    function initialize(bytes memory newModulus) external initializer {
        _setOwner(newModulus);
        emit MynaWalletInitialized(entryPoint(), newModulus);
    }

    /**
    * @notice Validate UserOperation and its signature, currently only supports RSA signature
    * @dev Internal function
    * @param userOp user operation
    * @param userOpHash hash of the user operation
    * @return validationData 0 if valid
    */
    function _validateSignature(UserOperation calldata userOp, bytes32 userOpHash)
        internal
        override
        returns (uint256 validationData)
    {
        bytes32 hashed = sha256(abi.encode(userOpHash));
        (bytes memory modulus, bytes memory exponent) = getOwner();
        uint256 ret = verifyPkcs1Sha256(hashed, userOp.signature, exponent, modulus);
        if (ret != 0) return SIG_VALIDATION_FAILED;
    } 
    ...
}

initialize(bytes memory newModulus) external initializer

During the initial verification phase of the first UserOperation, if the user’s proxy has not been deployed yet, it will be deployed and initialized with the user’s modulus.

_validateSignature(UserOperation calldata userOp, bytes32 userOpHash) internal override returns (uint256 validationData)

In order to execute UserOperation, we validate signatures by referencing the saved modulus and a constant exponent during the validation phase. If the signature is verified, the EntryPoint contract proceeds to execute the UserOperation in the subsequent execution phase.

Because our contracts are based on eth-infinitism, each user’s account is a proxy that references the implementation contract and our factory contract deploys each user’s proxy.

If you’re interested in exploring the details of our implementation, the implementations we referenced, or any related references, you can consult the following links for additional insights.

Looking ahead

As we move into the next week, we have several key initiatives on our agenda. Now that we have a draft of our contract wallet architecture, the next step is to begin coding the actual contract prototypes. This will give us a practical framework to evaluate and refine.

Moreover, at the moment our focus has been on basic functionalities. However, we’re keen to brainstorm and list additional features that could enhance the utility of our project. As always, we’re committed to keeping you updated every step of the way as we further refine and develop MynaWallet.

References

Contributors

Whose Myna Card?

Myna Card

About a42x Inc.

a42x Inc. is developing a wallet system and digital auth infrastructure. Main achievement: Selected as a finalist at ETHGlobal Tokyo, one of the world’s largest blockchain developer competitions.

Recruitment of Developers/Researchers

At a42x Inc., we reinforce hiring in a wide range of positions, including iOS & Android app engineers, backend engineers, researchers, and business development. We look forward to applications from those with a strong interest and curiosity in technology and craftsmanship and a passion for creating products used in the real world. For details, please get in touch with the email address below.

Contact

info@a42x.co.jp