Is ƒractally building on EOS?

ƒractally is built on the values of true democracy and community independence. We aim to integrate with all blockchain communities because everyone benefits from Mutual ℝespect. We believe that ƒractal’s should operate on a platform that values fractal governance and true democracy. EOS has an opportunity to migrate to ƒractal governance, but it will take a firm commitment of the EOS Network Foundation and Block Producers as demonstrated by a commitment to subsidize a governance ƒractal’s Mutual ℝespect with 2% annual EOS inflation and empower this ƒractal with power to appoint 11 of the 21 block producers.

This will ensure that the EOS network has a sufficiently decentralized governance system that factors in both true democracy and token-weighted opinions. This is a necessary step for EOS to become a DAO of DAOs. ƒractally would love to see EOS be home to countless ƒractals.

What is the future of Eden on EOS?

The Eden community is the first generation of fractal governance and has received funding from the EOS Network Foundation. They will have their next election on April 9th and ƒractally will provide services to host the election process.

The ƒractally white paper represents our proposed bylaws that will bring new energy and accountability to Eden. If the Eden community agrees they can elect a new set of Chief Delegates on April 9th and this new set can approve the funding required to migrate Eden to a fully functional ƒractal.

What is ƒractally doing with Mandel?

ƒractally is developing a suite of next-generation DeFi standards, including a token standard, nft standard, premium name system, premium token symbol system, and decentralized exchange. These standards are required for ƒractally to realize its vision.

Furthermore, ƒractally has plans to build faster finality, support synchronous calls, and a key value database api. ƒractally has submitted a proposal to the EOS Network Foundation to build a minimal viable product including all new DeFi standards. We would charge 700,000 EOS for these system contracts. An additional 800,000 EOS will buy faster finality and synchronous calls.

Why does EOS require a new Token Standard?

The existing EOS token standard was designed around the “require_recipient” paradigm for handling deposits and withdrawals. This legacy design allows user contracts to abort transactions when a transfer is initiated. As a result, contracts dealing in tokens have had to implement a “deposit” / “withdraw” process. This creates “balance” tables in every contract. The result is code bloat and security vulnerabilities. A single math error or hack of a contract can drain all “balance” tables that contract is maintaining on behalf of its users.

Furthermore, self-governing DAOs have the power to upgrade their smart contracts at any time. This makes it impossible for them to make long-term commitments with respect to token inflation rates.

The new token standard will allow anyone to create a token, with or without a symbol. This will utilize a common contract account shared by all tokens. DAOs will receive call backs to override token behavior giving them full control over everything except increasing inflation beyond chosen limits.

The new deposit/withdrawal process will no longer utilize “require_recipient” because we feel this feature should be deprecated. It will move all the “credit” tables currently managed by every smart contract into the tokens contract. This will ensure that contracts can send and receive funds without worrying about notification handlers aborting their transactions.

Furthermore, every token will be uniquely identified with a 32 bit ID and can optionally be paired to a global Symbol registry. This greatly reduces RAM requirements for DeFi applications, ultimately reducing developer costs and further increasing the attractiveness of EOS as the premier DeFi platform

Why does EOS require a new NFT Standard?

Existing NFT standards are focused on “art” and “collectables” and are not suitable for the multitude of non-fungible assets with which one could want to interact with on a DeFi platform. Under the proposed NFT standard, NFTs are nothing more than a unique 64 bit number whose ownership can trade hands using an API similar to the new token contract.

Higher-level standards (e.g. AtomicAssets) can still be used to facilitate the creation and exchange of specific NFT assets. Ideally all higher-level standards would upgrade their smart-contracts to utilize our core NFT infrastructure in order to enjoy higher security and better interoperability for lower cost. To this end, it may be more appropriate to think of our proposed NFT standard as a “standard of standards.”

Premium Names, Symbol Names, Accounts, and token issuer permissions are 4 items that will leverage the new NFT system out of the gate. Anyone who wants to create a tradable bundle of permissions can utilize the new system.

Why does EOS require a new account naming system?

The 12 character names supported by EOS were never intended to be user facing. Instead, they were meant to be an implementation detail similar to how account numbers are an implementation detail on BitShares. They were made “human readable” by interpreting a 64 bit number as base32.

We propose making the existing account names an implementation detail and adopting longer 32 byte names. Furthermore, we propose adding a new 32 bit number to uniquely identify accounts. This will reduce RAM requirements for contracts and make faster database lookups as both names and tokens will be identified by 32 bit numbers. This allows an account/token pair to fit in a single 64 bit index.

The existing premium name auction is time consuming and frustrating for users. Names under our proposed system would have a “buy it now” price that automatically adjusts based upon demand.

What does the proposed token standard look like?

The following sequence diagram shows how a user Alice which goes by a 32 bit user number (u1) buys the token ticker symbol CAT and then issues a new fungible token type and assigns CAT to be the ticker symbol.

The lines represent actions or inline actions, the boxes represent smart contracts, and the dashed lines represent context-free-inline actions (aka events) sent to an account with no contact on them. 

This diagram does not reflect the option for “auto-debit” which eliminates the need for Alice to claim the tokens sent to her. 

You will note that two NFTs are created, one for the CAT symbol, and another for the issuer permission on the fungible tokens. 

The following diagram shows how the new NFT standard can facilitate trading of accounts on any DeFi application that supports the new standard. This means that accounts, issuer permissions, symbol names, and premium account names can all be used as DeFi collateral. 

 

How will the new standard impact existing token contracts?

We would provide a token bridge contract that would automatically and trustlessly allow anyone to migrate an existing token hosted by private contracts into a token managed by the new standard. Users would be able to seamlessly convert back and forth between the old and new standards.

Why do the block producers have to approve the new standards?

We feel that broad community support for the standard is key to its success and that accounts that start with ‘eosio.*’ are more trustworthy. The new account name buying system will require some updates to the existing system contract to avoid ambiguous collisions between the old and new way names are allocated. This will be critical for security.

Will this require updates to the /v1/ API and to other APIs?

The /v1/ API will forever be the /v1/ API. New APIs may be provided to simplify access. Enhancements to these APIs are not part of the proposed work.

Will this require updates to contract SDKs and client SDKs?

Anyone wanting to leverage the new tokens would want to utilize the new libraries in the new SDK.

How will this affect existing wallets?

Supporting the new standard will require all user interfaces to be aware of new actions, balance tables, and name/number registrations. ƒractally would provide a reference implementation of such an interface. Existing wallets and user interfaces who choose not to update will continue to be useful only for interacting with the legacy tokens, symbols, and names.

Is Eden on EOS a DAO?

Eden 1.0 is an organization that maintains a balance of EOS which is distributed among its members according to periodic elections. In the event the EOS tokens were lost contrary to the intent of the Eden members the organization would cease to have a budget. Accordingly, Eden 1.0 is not a DAO because it is not autonomous.

In the event Eden becomes a ƒractal, it will have its own token and become a fully autonomous DAO.

Is EOS a DAO?

The EOS network has its own transparent ledger and can be forked by the community in the event consensus can’t be reached. EOS leverages Delegated Proof of Stake and can be held accountable to the community opinion. Hive forking from Steem demonstrated how a truly decentralized and autonomous community based on DPOS can resolve governance disputes.

While EOS may be autonomous, its current governance structure is centralized in the EOS Network Foundation under Yves. Aside from Eden on EOS, budgeting decisions are being made in a centralized manner and the typical EOS user has no practical recourse if they disagree except to sell EOS.

EOS can adopt fully decentralized ƒractal governance to return power to the users of the platform and decentralize funding decisions.