Part II. The OtoCo Ethereum smart contracts

This section describes the smart contracts design of our series deployment via the otoco.eth LLC assembler.

The smart contract for the Delaware and Wyoming Masters together with all other OtoCo code is available in our GitHub.

Series deployment

Each OtoCo entity is represented by an NFT minted by the OtoCo Master contract. Company information, such as the name, is contained within the metadata of the NFT, which can be looked up on Etherscan.

The owner of this NFT will have Manager privileges of that entity within the OtoCo dashboard and be able to add and remove plugins, initiate funding launchpools, sign documents, and more.

Various “jurisdiction”-specific contracts (for Delaware Series LLCs, Wyoming Series LLCs, and Unincorporated DAOs) are responsible for fetching the proper name formatting and metadata regarding the entity, and several plugin contracts work to add features to entities within OtoCo.

We will dive deeper into some of the most important functions within OtoCo’s smart contracts in the next three sections.

1. OtoCoMaster.Sol

This contract contains methods that allow OtoCo to receive payments and deploy new companies. It also contains a list of deployed entities as NFTs, with their details.

There are Administration Methods (only callable by the Manager of the contract) and Public Methods.

Key Administration Methods:

  • initialize(): Initialize the implementation contract and create initial jurisdictions.

  • changeBaseFees(): Set the new base fees to be paid in ETH along with the dApp transactions.

  • addJurisdiction(): Add a new jurisdiction to the network.

  • withdrawFees(): Withdraw the ETH stored on the contract.

Key Public Methods:

  • seriesCount(): Return the total number of series, across all jurisdictions.

  • baseFee(): Base fees charged for entity deployment/closing and plugin attachment/removal. This amount is a percentage and represents a value in ETH that needs to be sent along with the transaction.

  • createSeries(uint16 jurisdiction, address controller, string name): Create a new entity and set the controller. In order to create a new series, it is required to set the jurisdiction, name and the controller of the entity.

  • closeSeries(uint256 tokenId): Close the desired entity. This function can only be called by the controller of the entity.

2. OtoCoJurisdiction.Sol

This contract contains the entity naming rules and metadata for the NFTs. It can be used to add new jurisdictions, with their own rules, to the OtoCoMaster.sol contract without requiring an upgrade to the contract.

Key Public Methods

  • getSeriesNameFormatted(uint256 count, string name): Format and return the entity name to map the requirements of the jurisdiction.

  • getJurisdictionName(): Return the name of the jurisdiction.

  • getJurisdictionBadge(): Return the default NFT image URI for the jurisdiction.

  • getJurisdictionGoldBadge(): Return the original edition NFT image URI for the jurisdiction.

3. OtoCoPlugin.Sol

This contract introduces a key element of composability to OtoCo, in line with our vision to make it an open architecture platform where users can add various bolt-ons to their entity.

To achieve this, we use the OtoCoPlugin.sol contract which allows for each plugin and feature within OtoCo to have a dedicated smart contract (such as Token.sol), with the main plugin contract providing functions inherited by plugin-specific contracts.

Key Public Methods

  • otocoMaster(): Reference to the OtoCoMaster contract to transfer ETH paid for services. This function appears on all plugins, which makes it possible to verify the correct OtoCo Master attachment.

  • addPlugin(uint256 tokenId, bytes pluginData): Add the plugin to the entity selected according to the parameters selected.

  • attachPlugin(uint256 tokenId, bytes pluginData): Attach a pre-existing plugin to an entity.

  • removePlugin(uint256 tokenId, bytes pluginData): Remove the plugin to the entity selected according to the parameters selected.

Implementation

To cover the implementation side of OtoCo, we will now walk you through the example of a user creating a Delaware LLC and attaching the “token foundry” plugin.

When an entity is created on the front-end of OtoCo, the createSeries method from the OtoCoMaster.sol smart contract takes three key parameters:

  • Jurisdiction—the jurisdiction of the entity, selected by the user

  • Controller—the address of the Manager, which is the wallet address the user connected with

  • Name—the entity’s name, chosen by the user

At the moment of creatrion, an internal transaction will be made to a jurisdiction smart contract to return the proper formatting of the entity’s name according to where it is based, in our example Delaware.sol.

The key methods from OtoCoMaster.sol, such as createSeries, can be seen in the code snippet below.

function createSeries(uint16 jurisdiction, address controller, string memory name) public enoughAmountFees() payable {

        // Get next index to create tokenIDs

        uint256 current = seriesCount;

        // Initialize Series data

        series[current] = Series(

            jurisdiction,

            0,

            uint64(block.timestamp),

IOtoCoJurisdiction(jurisdictionAddress[jurisdiction]).getSeriesNameFormatted(seriesPerJurisdiction[jurisdiction], name)

        );

        // Mint NFT

        _mint(controller, current);

        // Increase counters

        seriesCount++;

        seriesPerJurisdiction[jurisdiction]++;

    }

Typically in less than 1 minute after the transaction is submitted, user will have the entity activated, with legal validity in the chosen jurisdiction (either Delaware, Wyoming, or as an unincorporated entity in the case of an Unincorporated DAO).

The controller’s wallet (Manager) - which can be a multisig or even a DAO contract! - will hold the NFT and enjoy Manager privileges (see above).

If user would like to add a plugin, such as OtoCo’s “token foundry” to create ERC-20 tokens (for instances to create mirror tokens reflecting % Membership in the LLC by multiple Members), user will submit a transaction to the Token.sol contract. The addPlugin method will act as an initializer and read the parameters from the plugin the user is trying to add.

In this case, parameters for the token foundry are:

[uint256, string, string, address] that represent the token's totalSupply, name, symbol and the holder that will receive the total supply of the tokens after deployment. This can all be seen in the code snippet below.

function addPlugin(uint256 seriesId, bytes calldata pluginData) public onlySeriesOwner(seriesId) transferFees() payable override {

        (

            uint256 supply,

            string memory name,

            string memory symbol,

            address holder

        ) = abi.decode(pluginData, (uint256, string, string, address));

        address newToken = Clones.clone(tokenContract);

        ISeriesToken(newToken).initialize(name, symbol, supply, holder);

        tokensDeployed[seriesId].push(newToken);

        tokensPerEntity[seriesId]++;

        emit TokenAdded(seriesId, newToken);

    }

This contract will deploy the ERC-20 token contract along with sending the balance to the addresses specified by the user who initiates the token foundry contract.

Up to this point, we have used OtoCoMaster.sol to create the entity, Delaware.sol to format and return the name and metadata about the jurisdiction, and Token.sol to deploy ERC-20 tokens.

Creating an entity based in a different jurisdiction, and attaching a different plugin, follows a similar implementation pattern and many of the same methods—but with contracts specific to those features.

The following links direct to the addresses of each of the plugins below:

Smart Contract Audit

OtoCo's smart contracts were audited by Coinspect in May of 2022.

Their audit report highlighted a few relatively minor issues, all of which were addressed in a matter of days. Corrections and updates were submitted to Coinspect based on their recommendations, and documented changes can be found on our Github.

The full report of Coinspect's findings and validation of our updates can be found below.

Last updated