The Code Market

Community Driven

built on eosio

v2.3.1 - 2019-10-25


Nowadays, when humans are united by common goals and interests more than by territorial or some other casted dependencies, the role of states acting as centralized administrators diminishes, and causes the worry to a handful of rulers, who most often, as a rule, possess just personal interests in maintaining the power.

Once upon a time the aim of the State was a common good of its citizens. The human draw towards egoism and the natural instinct of survival to be superior and more advanced than any other individual, the constant fight for a place under the Sun has been grown into our blood since being animals, caused and encouraged not only a game without rules and an all-around progress, it also crumbled and diminished the concept of common good as the idea of common goal.

If you realize today's technological possibilities in uniting humans into autonomic decentralized communities, the power of such communities, and if you have ever felt your hair rising from an excitement, then you know how we are excited to invite you to join us on the front row, not only to observe, but also to build a way together towards the common goal.



The Problem

Currently, all cloud based source code repositories and distribution is handled by privately maintained profit oriented companies like Github (by Github Inc., USA), Bitbucket (by Atlassian Pty.Ltd./Inc., Australia), GitLab (by GitLab B.V., originated in Ukraine but rebased to USA), Launchpad (by Canonical Ltd., UK), and many others. Most of them are even proprietary code based, while SourceForge, which is in decline and has already the 3rd owner, is the only major open source player. This leaves basically all global developer community with having their code repositories serviced by privately owned, profit oriented organizations and closed source infrastructure, while most of them are all based on open source git code repository backend. While both Github and Bitbucket offers free to use options for open source code repositories (bitbucket even offers free plan for micro proprietary code developer teams), proprietary code repositories need a constant paid subscription to be online. Even worse - proprietary code repositories silently are carrying the infrastructure costs of open source code repositories. While this may seem altruistic from such organizations and open source community supposedly should feel grateful, the aspect of centralized control to which community has no voice and that the future is unknown are both apparent.

The question of security and persistence is also valid here. Any repository on, let’s say Github, is alive only until Github is online. If Github fails or goes down forever, the repository with it goes as well. OK, due to distributed nature of git the code will stay on local machines of developers and ones who cloned it, but further collaborative work on it won’t be possible without a new centrally hosted code repository. How it affects related repositories which use it as dependencies? Catastrophically because of URL dependency and manual intervention necessary. Hosting, serving and managing code repository through blockchain is the answer, as the persistence of the repository becomes basically eternal.

Furthermore, the fact of thr existence of the code in private code repositories is basically void to the World of developers except for its owners, maintainers and developers who work with such code. This leads to perpetual “reinvention of the wheel” over and over again instead of improving the already existing “wheels” more collaboratively. Competition also exists in the open source world, but also does collaboration and reusability. Currently software development market is undersupplied, and in such an inefficient way that everyone is solving the same problem in over-competitive manner and perpetually wasting time. And this mostly happens just because such private projects and thus private code repositories are not discoverable by any means. Nobody can buy and reuse the unknown.

The solution

Blockchain infrastructure based git code repository service with public metadata and secure smart contract licensing. Instead of depending on financially and organizationally vulnerable centralized infrastructure, where centralized owner can make decisions over the community code and dictate terms, the infrastructure is transferred to the DAC - Decentralized Autonomous Community itself. Initially, all produced content going through git and the blockchain will be hashed and checksummed, where these hashes and checksums will be screened against everything it is know, and as metadata collected and stored in the blockchain. Also, URLs for accessing secure git storage providers would be stored on blockchain as well, making the dependency inclusion aspect solved even if physical code hosting would be moved or would go out of service. In codum we propose to to do it securely, the code repositories will be encrypted and stored in the blockchain controlled storage nodes. Commits entered into repository will remain forever as long as network lives, unlike corporate entity dependent alternatives we have now. By utilizing the DPoS (Delegated Proof of Stake) Blockchain, infrastructure participants will earn their fair share for delegating their resources to the community infrastructure.

As in current commercial implementation of existing code repository services, public open source code co-exists with private proprietary code in the same infrastructure anyway. By adding the publication capability of the metadata and taxonomy for the private code repositories, codum also provides the so missing visibility feature for the proprietary code - the value of discoverability:

  • For owners of the code: ability to source and profit from the code by licensing it under smart contracts at any stage of the code lifecycle.
  • For developers of the code: added value to the work history and profile, and ability to save valuable development time by discovering and outsourcing the existing code from other private repositories in addition to what is available in the open source.
  • Both sides benefit from wider code reusability and easier integrations naturally happening due to the fact that larger and larger parts of code become common across their projects, making projects to be developed faster while reducing the maintenance costs and shifting the responsibility.

All the transactions are formalized in the smart contracts between the parties.

Licensed forks of private repositories may never become open source without the decision of the owner of the parent private repository, while the minimal metadata of such repository would be public without an option. This enables the accounting of chain forking and cloning added to such metadata of all repositories.

Code theft detection is integrated in codum as well: in case cloned/forked repository content appears in the network as a new repository by at least some part, both owners are notified of each other. Such checks are performed by the blockchain infrastructure knife nodes where finders are rewarded from the revenue share.

Additional values are provided by creating the integrated project management, developer sourcing and market capabilities to the system. Developers gather their portfolio profiles by participating in the projects, both open and proprietary, where such profile data can be used for developer candidate selection process within the system. Employment can then be formalized as a smart contract and payment processed on acceptance merger. Also, both contract sides - the developer and his customer - can rate each other and the rating weight will depend on the smart contract overall value, on top of the success rating gathered from the metadata of the related developments, including such data as estimate overshots, declined pull requests, failed tests and so on.

On top of that all good, software development driven CODUM token emerges, together with this newly created development and licensing economy. When developers will be making transactions in any preferred crypto or FIAT currency, CODUM token will act as a seamless intermediary token in exchange. CODUM will start to gain a momentum in valuation driving all internal economy upwards. And in the long run, developers will start to prefer CODUM as a way of payment. Additionally, software licensed through codum will gain demand in mass of the software consumer market with time, becoming the standard in software licensing.

Platform Overview

Public Website Frontend

  • Representative content explaining the codum platform - what it is and how it works
  • Platform services and user benefits
    • Account Management interface
      • Registration for Users and Organizations
      • Profile Editing and Statistics
      • Account Access Management
      • Wallet and Smart Contract Management
    • Project Management interface
    • Source Code Management interface
    • License Management interface
    • Contracting interface
    • Infrastructure Management interface
  • Integrations
    • 3rd party KYC provider
    • 3rd party inter-blockchain token exchanges
    • Social networks (Stack Overflow, Stack Exchange, Github, Facebook, Linkedin, Twitter, etc.)

Source Code Repository Management Frontend

Essential functionality for browsing source code repositories like in Github. Including, but not limiting to essential code review and collaboration functionality, served with a different and enhanced User Interface with seamless integration of Project Management with Agile Boards, Task backlog, states, time tracking and insights. In addition to that, it will be fully mobile friendly and operable at all levels - allowing all collaborators to have full control of the situation on the go: from manager being able to redistribute tasks and check on overall progress across the projects, down to developer being able to make a quick fix and see if it builds, and then deploy it.

Open Source Code Repositories

All registered and anonymous users are able to see and get everything - source code of all branches, builds, releases, commits, pull requests, related issues in the project management board, and all related entities. Registered users can participate in all development process of public/open source code repositories - fork, code, commit, push and submit a pull request. However, integrated task management helps to easier track progress and assign commits to tasks even after their submission, so it will never be too late to add that comment to commit message.

Owner of the repository is the de-facto moderator/maintainer of the repository as well and is responsible for its content and licensing. However, such roles can be redelegated. Multisignature smart contracts integrate on all levels of codum functionality.

Cloning and forking is not restricted for open source code repositories, however, distribution and derivatives can be enforced by the license if owner/maintainer decides so. Initially it is planned to implement and support GPL 3.0, MIT, BSD, Apache 2.0 license smart contracts.

Private/proprietary Source Code Repositories

These work differently than it is implemented now in Github or Bitbucket. The owner of the repository is the user who decides what level of metadata is publically accessible, and what is not. The owner also can delegate responsibility and access to other users or user groups, and roles and access groups logic is shared between code repository and project management functionality. However, license acquired user access is controlled by the license where licensee manages his own access keys, and the same goes for the contracted developer access where smart contract takes over access control duty.


All git repository services are free of charge. Only a small commission of 10% fromt the transaction amount is being taken from licensing and developer sourcing contracts.

Public Metadata

The so missing feature in existing private code repository services. It includes the following data and publication of each position is optional unless Licensing is enforced by Smart Contracts:

  • Repository name, repository owner/maintainer users and participating users
  • Public readme file of choice (most text formats supported)
  • Human readable ricardian Licence Smart Contract
  • Technical git metadata (branches, commit hashes, commit checksums, file checksums).
  • Semantic code representation
  • Links to Knowledge Base and Project Management entities

Secure Licensing

Licensing of the source code repository becomes available with the above mentioned Public Metadata feature. Once licensing is enabled, for it to work, all Public Metadata features must be enabled on the proprietary code project. Due to proprietary nature of such repositories, they cannot be used in open source projects even as dependencies unless the Owner’s repository becomes fully public/open source - the dependency links still can be made but submodule functionality will just not work if user does not possess the License Key to the repository. Licensed repositories will only be able to be accessed via SSH private/public key pair authentication where public key is also a stored on the data tables in the smart contract.

Initially Planned Smart Contract License Templates

Clone License

Accounts for “use only” case of license, where Client is entitled to clone the repository for the License fee agreed by the Smart Contract between the Owner and the Client, where Client is granted the Clone Key Certificate. It is SSH security key which entitles the Client read access to the licensed code repository branches and commits. Multiple pricing options are available:

Branch/Commit Limit

Each `git clone` action is charged to the Client a full license fee, while `git pull` action is charged to the Client the update fee, but only in case the commit is newer than the one stamped on the license. All current or older `git pull` or `git checkout` actions are not charged. `git fetch` is free of charge all the time.

Periodic Subscription

Each `git clone` action is charged to the Client a full license fee, while `git pull` action is free of charge for the subscription period. If subscription is expired and not renewed, it becomes Branch/Commit Limit Clone License stamped with the latest commits before the expiration timestamp.

Clone Redistribution License

Enables the Client to include the licensed repository as a dependency to his proprietary source code as git submodule. The Distributor then receives the Redistribution Key Certificate for the repository, which can be used to access the repository by chain. the Owner of the licensed repository receives the benefit of Licensing to his code where perpetual Clone Licenses are issued on demand.

Fork License

Enables forking of the repository, where the Client is granted the right to source code derivatives and further redistribution, thus creating the possibility for the Client to participate in the development process. However, Client and Owner must agree on redistribution, intellectual property and other terms. It is possible to set the Client free of obligations as well as restrict it to any physically definable bounding limitations.

Pay per Merge

Each merger from upstream is charged the update fee to the client in case there are physical changes in the repository

Periodic Subscription

enables unlimited mergers from upstream for the defined subscription period in the Smart Contact.

Contracted Developer’s Forking

It is a special license issued to the contracted developer with the ability to gain custom read/write access to the project with the ability to fork the repository. However, such license strictly limits the redistribution, including derivatives. Furthermore, the developer with all related contact circles are the first targets of the Knife - so called unlicensed redistribution guard algorithm.

Pull Request

Enables the Client’s developers to contribute to the Owner’s project and even get paid for it. Issued Pull Request appears on the Owner’s repository (changelog, documentation, changed files and lines and the price). The owner can, from that moment, pull the changes, build and test the submitted code, etc. However, the Owner is not holding any rights to the contributed content before merging the pull request, or fulfilling the conditions in the Contract. Knife will work on the benefit of unaccepted/unfulfilled pull request contracts in case such content appears magically in the Owner’s code repository. When the Owner accepts Pull Request, the Client is getting paid for the contribution. If PR submitted content later appears in the Owner’s repository, the Client has a right of compensation and financial obligation of the PR Smart Contract may be executed fully or in parts depending on the situation, and in case defined details in the smart contract are enough to do so, it will be done automatically and immediately.

Knife - protection against unauthorized distribution, license violations and theft

“Because it has to be served with the fork”

Blockchain infrastructure providers, motivated by an additional reward opportunity, will be running the Knife operations - theft protection algorithm for code repository owners to enforce licensing terms. The Knife will run on codum Knife nodes and will check everything against everything. The algorithm running on the infrastructure Knife nodes compares the metadata of the existing and newly uploaded content or it’s changes to the metadata of any other repositories known to the network. In case a match is found, both parties (owners of the repositories) are informed of each other. In case of a Licence breach, the repository containing the suspected unlicensed content is suspended from any commercial/licensing operations before the parties resolve the issue, the Owner discards the claim, or no-response timeout happens which is relatively short. The contract is automatically recurring and gets suspended only when there are no more unchecked commits left. The Knife contract is changed from search mode to listen mode. In search mode, the bounty contract is comparing the licensed content to everything is known on the blockchain. In listen mode, everything coming to the blockchain is compared against the licensed content.

System Imposed Knife limitations

For performance reasons, Knife algorithm will prioritize search and will try to find the infringement in logically first possible suspects and repositories according to the metadata existing about the search criteria. First only file metadata (like size, file type/content type, line count, checksums) will be compared. For example, Javascript code will never be compared against C++ code, as it makes no sense. Also files which differ greatly in size and line count will also meet last. Also content which is known as open source content with derivatives allowed and unlimited distribution license terms, will be excluded from the search criteria ignoring any and all false claims to it from both sides, however, timestamps do matter and newly coming content with unlimited licenses will be checked against all there is known. These rules will also enforce private repository owners to properly license such publicly available content even in their private licensable repositories.

Legal Implications

There will be cases where codum licensing and real world intellectual ownership of non-material property will clash, especially in the early days of codum life. The process of solving such legal issues is well thought through and the solution exists. There are many ways to separate genuinely developed project from archived dump of source code and this will be taken into account. For example, source code repositories forked from other sources into git, or otherwise having a development history, will have more rightful weight against file dump after git init into a fresh source code repository. There will be also a way to link existing Github, Bitbucket and other 3rd party provider accounts and prove the authenticity. With these mentioned information sources, the owner and the violator can be distinguished inside the system trustlessly without any human input. In all other cases, where manual decision and legal process will take place, the real source code owner has what to show for it, and is an active maintainer of such code base, sporting the knowledge of most recent issues. The only problem we might have is contract IP infringements of the developers to their customers, and even these partly can be solved by above means, or manually by processing related documentation. In general, such issues would be relevant only at the very beginning where source code would be developed outside the codum development environment, and will be lived out with time.

Knife Crawler

At the later stage of codum project, Knife Crawler will be created, performing search engine crawling services across all known publicly hosted git source code repositories and collecting minimum viable public metadata on their content. This would be done in order to protect both sides from license and IP (intellectual property) violations. Git providers, blocking the crawler, would be considered outright violators and legal actions would be taken to enforce the access. On other hand, the crawler would be operations could be arranged through robots.txt file of the provider’s site, declaring traffic limitations and optimal off-peak hours for doing the crawl, however, both hours and traffic limitations cannot be above 10% of the provider’s capability. Also, crawler would be operating using git protocol and would never redownload unless integrity of the known repository is compromised, thus saving the provider’s resources.

Project management frontend

Setting up a project - creating and running the board, task backlog, workflows and development processes, roles and rules for developers, time logs and code delivery performance tracking, issues and reviews - all of that every software project needs and what is Project Manager’s primary responsibility. The ability to execute and run everything close to the source code repository is the key to success for the project owners and managers - as it is running the project all in one place, compared to multitasking across a handful of software. The ability to handle Client and Customer relationships and communication, connecting the issue tracker and backlog, eliminates a lot of misunderstanding and eliminating transparency issues greatly improves project’s performance.

Business Use Case - assemble the team for your project

As a business manager, you just simply create and fund your account personal, create a project and describe what it is about. Project can have its own balance account, or project can be funded directly from project owner’s account. When the project is published the project’s CTO decision must be taken, where CTO can be hired, delegated or project owner can take it on it’s own. In all cases the project’s CTO role, indifferently from any other founding/board team members from technical perspective, is set up as a smart contract defining responsibilities and rewards, and these can be set up once they are necessary. In case project owner has no technical person available to take the CTO position, codum system can suggest, depending on keywords used in the project’s description, from the global pool of currently not engaged in projects, experienced in project management users. At the same time, such users will see this project in their project opportunities board, where they can bid their offers to the project owner.

Developer Sourcing

Established infrastructure of source code management and distribution together with project management and internal token driven economy creates the perfect space for one more component in the system - software developer sourcing. And most of the components and infrastructure are already up in place. We have published private project metadata, tasks and code access licensing. And we can implement a chain of smart contracts for executing the developer sourcing.

CTO breaks down the project into components and tasks. Development methodology here is open and any of them can be adopted, be it lean, agile, waterfall - you name it. Job offer and the issue or task in the backlog is one and the same thing. Then, developers can be sourced through the codum in a similar way CTO was sourced:

  • CTO and the project owner will see the available candidate suggestions depending on their experience in similar past tasks, and developers themselves will have opportunity task lists which they can bid to work on.
  • Developers bid their offers to execute the project with their set hiring conditions and estimates. Developer decides payment terms, but CTO can negotiate it, or CTO sets them on tasks right on their creation.
  • Once the arrangement between parties is made, it is formalized as a development sourcing smart contract with all conditions, like specification, quality guidelines, rules, terms, deadlines, payment terms and so on included and enforced by such smart contract.
  • Conditions agreed on and signed as a Smart Contract become binding.

CTO also makes decision on the workflow with the code repository, either giving permissions to the repository branches for each task, or allowing developers to fork the repository for themselves and submit a pull request to designated branch. In any case, the merge operation must be performed as an acceptance proof and resolution for both sides.

  • In case code repository is private, during the employment time the developer gets Contracted Developer’s Forking license to the private repository in case of fork-PR workflow. Otherwise - clone license.
  • Developer, in the process of the developments, submits his Pull Request with contract of acceptance, which also has binding implications to the Employer/CTO/PO. Even if PR was not ever accepted but the content was recreated, the developer has a right to the compensation.

Ranking, rating and reputation

KYC is required for all users of the system - customers, developers, arbitrators. All EOS/codum accounts will need to get approved manually, but this process is to be automated when reliable 3rd party KYC solution is found. There will be no codum holders using any codum service with unapproved eos account.

Developers build their experience and profile with every commit they perform in the system. That includes work on private repositories with published metadata. At the same time, repository owners can showcase their developments at any stage once the metadata of their private code is public.

Rank would be the representation of the weight of total developments performed or owned by the user. Participation is rewarded with rank no matter the outcome.

Rating is the ability for contract sides to rate each other. Developer can rate Employer and Employer can rate Developer at closing of the contract. In addition to such rating, successful contract adds to the reputation and failed contract subtracts from it, balancing the human factor. There is also a pattern driven abuse detection algorithm in place to avoid grief or subjective ranking.

Reputation calculates from the ratio of the rank and weighted average rating, and the price of the weight is determined by the time spent on the task, lines and bytes of code produced, and the price of the contract once Developer Sourcing is implemented. This weighting allows to avoid the situation where a few unsuccessful days of work across freelance contracts may ruin the reputation gained in the years of development. However, if the developer manages to pull out a unicorn project in a ridiculously short period of time, it may be recognized accordingly.

The Economy

To make the CODUM token a liquid and feasible utility token it has to become the token driving all the operations performed in the codum service network, be it codebase access licensing or sourcing developer work. The token will be placed in exchanges for additional liquidity. As the codum platform use grows with time and it’s demand rises, the valuation for CODUM token and all related cryptocurrency valuation goes up as well. The infrastructure providing the services of the platform needs codum as a fuel to run on, while the demand for such services forces the acquisition of CODUM in exchanges from other currencies. Project Owners can receive CODUM for licensing out the access to their code repository and spend it in the future to hire developers to execute the maintenance and further development. Then, Project Owners inline with other blockchain infrastructure providers and developers exchange their gained CODUM for other crypto or FIAT currencies to balance liquidity in the exchanges globally.

Competition analysis

GitHub pricing: $9/month per user, starting small teams $25/month includes 5 users. While corporate plans start at $21/user/month requiring additional features and guarantees which would be lived out by the blockchain infrastructure, thus reducing the overall market price.

Bitbucket pricing: free first 5 users, $2/user/month for small teams over 5 users, $5/user/month for large teams requiring additional features and guarantees. This price, however, excludes the project management features of JIRA or Trello, but includes some portion of pipelines and continuous deployment. These are sold as totally separate product with its own pricing, which is a head higher and even more progressive.

Both of the above include the money leaching for long term collaborators and maintainers participating in many projects, as even if they do not contribute any work for a certain amount of time, their presence is charged by the git infrastructure provider. If a developer is participating in 3 large corporate projects on github and takes a month vacation, his presence in the infrastructure costs it’s owners at least $63 for that month alone.

codum pricing

Revenue from licensing and developer sourcing commission, which is 10% on both, will generate so much revenue that it will cover all the infrastructure costs. 60% of the revenue is going to be redistributed for the infrastructure support and incentivization - which is more than enough. 40% of the revenue will land into codum's organization for the growth and expansion efforts, mainenance and further development of codum.

Costs of Operation

Domain name at .io TLD

59 €/year + VAT

Off-chain backend infrastructure cost

Currently it is 12 €/month + VAT per storage node and about 30 such nodes would suffice until codum needs to scale above 20k users or so. Linear scaling is possible for up to 100k users (by adding more CPUs, RAM and storage, up to 60 €/month), then we need to horizontally scale by separating and then parallelizing services and that could suffice for up to 1M users if architected well enough, still fitting within 300 Euro per month per node. Additional storage will be required with time, increasing the monthly cost at about 10% to 20% every year at all scales.

EOS infrastructure cost

CPU and Bandwidth requires EOS stake but does not cost anything in the long run. EOS can be unstaked at any time if capacity is underutilized. The stake can be delegated from other EOS accounts, and that is actually what we are looking at when it comes to production operation.

RAM cost is very dear, and RAM in EOS serves as on-chain permanent data storage. Even though codum is engineered to use as little as possible of such storage, due to the EOS and RAM price volatility it is the weakest point of codum economically. At the time of writing, 1kB of EOS RAM, just sufficient to record everything from git push transaction of a single commit of a few files, costs 0.0477 EOS or 0.32 €. The price of RAM needs to fall by 150x for it to be economically feasible even when considering storing just the minimum required portion of the metadata on EOS main network chain tables. However, by not storing the metadata into EOS tables, but just putting it into transaction parameters, would solve the RAM problem completely reducing it to 0 for this case at the cost of Knife needing to be a full EOS node with history plugin, running off-chain Knife comparison algorithm and reporting finds as transactions back to EOS network.

Fragmented git storage nodes

The recent development of fragmented git storage node concept will allow to drastically reduce the storage node running costs while increasing the security of the especially private source code repositories, as even node operators would be incapable to hack into their storage node data stores and assemble even a part usable content stored in there.

Sustainability of the codum infrastructure - Revenue Share Distribution

Owners of the staked CODUM tokens will get a revenue share from the turnover of the token in platform services. These include, but are not limited to: repository access licensing transactions, developer sourcing contracts, and all services introduced in the future where codum gets revenue and CODUM token is used.

    The revenue share payout will occur as soon as the revenue reserve account, which would be inaccessible otherwise, reaches 0.2% of the total currently staked codum. On the event of such payout, the revenue reserve amount is deducted from the revenue reserve account, while:
  • all the accounts containing active CODUM staked tokens get their stake value multiplied by 0.0006 which is added to their account balance, splitting 30% of the revenue share reserve.
  • the top 60% successful Knife nodes and all fragmented git storage nodes split 30% of the revenue share reserve, depending on their success and service rating respectively determined by the reported incidents. In case of no knife incidents reported, which is extremely unlikely, all Knife nodes split the share equally.
  • 40% of the revenue share reserve is transferred to the codum organization account, refilling resources required to compensate codum organization for managing and maintaining codum and further developing additional features.


Codum is designed to run and be managed by community. However, until it is technically implemented to function as such, it will be managed by team of delegates assigned by founders and advisors. However, in any point of time due to any kind of violation or disagreement with the majority of the community members of codum, any member of such team can be relieved of duties and replaced by a more suitable person to do the job.

Obstacles for complete decentralization

Classical internet and politics infrastructure, like domain names, branding and all patents on trademarks for codum and codum.io names. Until these can be handed off to the community control in a purely decentralized manner, the domain name and brand name rights are to stay with the founders.

Source code ownership of codum is to stay with the contributors to the codebase, however, anything committed to codum is to be licensed in GPL 3.0 (General Public License 3.0) terms.

Until secure long term private data storage can be implemented in a decentralized manner, such storage is to be managed by founder team and delegated contracted 3rd parties carrying legal responsibility of operating hardware and software storing such highly private data.

Source code control is to stay with codum founders and delegated core developer team until proper decentralized governance over code mechanism is developed and tested. However, such control will stay in the hands of most contributing in terms of value to codum.

Token Distribution

codum utility token is issued at 428000000 CODUM hard cap and will stay at that hard cap forever. The initial network spin-off is sufficient with as little as 1% but the peak network and economic efficiency would start at about 20% of the token supply in perpetual turnover.

Fundraising by Token Sale

Codum token, which are based on EOS and issued for sale and reserved, are equal in value and utility, and do not represent any equity in codum or codum.io organization or community. The sole and only purpose of the CODUM token is the utility in post-launch codum community network ecosystem, to be used for codum platform services inclduing software licensing and developer sourcing.

This token sale section is subject to change without prior notice until the version 3.0 of this Whitepaper is released, where codum will have clearly defined financial plan and will start the token sale process. No change to token distribution scheme is allowed once at least one codum token is sold, and thus such distribution will be hardcoded into the sale and distribution smart contracts. However, total token hard cap, soft cap, sale total token amounts are set in stone and will not be subject to change in case we will need to execute the token sale event.

CODUM utility token sale through MBI

The absolute maximum of tokens to be sold is capped at 235640000 codum. It is considered sufficient for funding the development and launch of the codum platform in full functionality provisioned by this white paper.

All the codum utility tokens are to be distributed through Milestone Based Issuance Standard.

The unsold tokens are reserved for the future public fundraising campaigns and for the community bounty for the development of codum. The purpose of such tokens is stimulation of codum post product release economy.

Reserved CODUM token distribution

Maximum of 192360000 c_ in case of total success in private and public sale, are reserved for distribution to founders, advisors and contributors to the codum development, and a small fraction reserved for company expenses in case the payments can be arranged in CODUM. In case of just breaking the soft cap on both sales, distributed token allocation can reach 367720000 c_.

The reserved tokens will be initially locked and unlocks at the rate of 10% per 6 months. The first unlock will happen on the estimated public launch date of codum, and the last 10% will be unlocked in 5 years after that.

Out of all reserved tokens after the sales has concluded, 100000000 to 275360000 c_ are reserved exclusively for contributors involved into the codum development and will be awarded through smart contracts on the merge event of pull requests through out of the development and the support of the codum platform.

5000000 c_ are used for promotional and social media bounty rewards during the sales.

10000000 c_ are reserved for the company expenses.

The rest 77360000 c_ are distributed to project founders and advisors.

Technical Background

This section is written with the assumption that reader fully understand the inner workings of both git and EOS.io blockchain.

Public Metadata

Publishing metadata will be optional for Private/Proprietary code repositories, but will be obligatory for the open source repositories, because not having it would make content of such repositories free for unlicensed grabs. Private code repositories not having public metadata will stay not discoverable as is presently. Portion of Public metadata will be a part of .git directory content in the code repository itself.

Commercially or otherwise sensitive private data, such as personal data (names, addresses, etc.), will be securely stored off-chain to be compliant with GDPR and other possible governmental regulations. Such information is to be centrally managed by founders and their delegated parties maintaining codum off-chain infrastructure until needed, and to be integrated into blockchain infrastructure once it is legally possible. It will be securely and periodically backed up to encrypted redundant undisclosed (but in case of emergency discoverable and accessible) locations.

Structure inside the Blockchain

  • Repository Meta (name, project, urls, type, where type is one of Open Source, Proprietary or Private)
  • Repository Access Data LayER (RADLER)
    • Permission and Access Control, where functionality is inherited from EOS.io with very minimal if any modifications
    • License access to git repository maintained by public/private SSH key pairs, where public key is registered to the metadata.
  • Branch/Commit tree meta:
    • Commit Hash
    • Timestamp
    • Contributor handle
  • License Smart Contracts
  • Meta contents of Branch/Commit/File(object/delta) tree:
    • File path and name hash
    • File size, commit change size
    • File type (binary/non-binary)
    • File line count and line deltas if non binary
    • File content type (text/html/python/cpp/hpp/image/pdf/exec/etc.)
    • File checksum hash of the current version. Such hash will allow file comparison without having the file itself, integrity checks and so on.
    • Current change checksum hash (same as file hash, only applicable to the changes of the current commit)
  • Dependencies - Submodule data from git with added Licensing Smart Contract parameters, such as redistribution keys

Structure inside Code Repository

.codum directory, if included, enables public metadata for the repository, with the following content:

  • Public readme file path or URL in .links file, symlink or README.* file itself
  • Human readable license file path or URL in .links file, symlink or LICENSE.* file itself
  • License Smart Contracts
  • Any 3rd party integration metadata, for example 3rd party Continuous Integration and Continuous Deployment solutions
  • .filehash file, storing meta contents of the current branch/commit/file(object/delta) tree. This file is generated for reference only as a result of the actual commit in git operation, and will never be used as a source for the blockchain data input in the future commits.
  • Any file in the repository has an option to contain filename.meta.md file, which may contain important data for the developers considering buying and reusing such code - for example, class descriptions, function headers, use cases, and so on. This would solve partially an issue of potentially buying bad code, as code with proper documentation and .meta descriptions on source files would make it more attractive and show more care and effort been done to support it. Any other document file formats, even filename.meta.docx, are also supported. Privacy disclaimer: all filename.meta.* files of private repository, in case the file itself exists, are considered publicly visible, thus the contents of these filename.meta.* files cannot be secret or otherwise commercially sensitive.

Infrastructure options

Git source code distribution backend running on blockchain infrastructure

EOSIO software driven public EOS blockchain infrastructure

Long Term Storage implementation in 3 stages

  • On initial release, git access to 3rd party git servers via SSH keypair only
  • Centralized cloud solution for redundant reliable LTS of codum managed repositories maintained by community under strict, legally binding liability agreements
  • Fragmented codum .git storage nodes

Current relative Open Source resources to look at

One option of principal implementation for decentralized git operations in torrent network is https://github.com/cjb/GitTorrent - it would require the client to install additional package. Another one is to make a gateway over http, both remotely and locally available, where local would of course require to install the gateway app.

Gitchain (https://github.com/gitchain/gitchain) is currently already unfeasible blockchain implementation on Bitcoin. It failed (2k$ real investment only on Kickstarter in 2014). We can salvage the experience with BitCoin.

GoGit (https://godoc.org/gopkg.in/src-d/go-git.v4) - A highly extensible git implementation in pure Go.

Git (https://github.com/git/git)

Team Structure

C suite

  • CEO / General Director / Liucijus Urmonas
  • CTO / System Architect / Kęstutis Januškevičius
  • CFO / Director of Finance / Vacant. Looking for financial expert with CFO experience in large corporations
  • CMO / Marketing Director / Vacant. Looking for a Sales Mastermind with public enterprise launch experience
  • CCO / Community Manager & PR / Karolina Jasaitytė

Team Leads

On the level with C when it comes to responsibility and decision making

  • Backend Dev. Lead / Vacant. Looking for Master C++ dev., EOS expert, git/open source master
  • Frontend Dev. Lead / Vacant. Looking for JS Master, Angular6+, eosjs2, scatter
  • UXS / User Experience Strategist / Tadas Lukoševičius
  • Lead Designer / Gediminas Skirmontas
  • QA Lead / Vacant. Looking for testing expert for backend/frontend capable to mock 5 levels of abstraction
  • Deployment Lead / Vacant. Looking for ELB deployment expert, security paranoid, Unix freak


  • On Yavin / CEO of Cointelligence / Business Development and Compliance
  • Makoto Tominaga / CEO of Credify and SportsLedger, eosDAC Custodian / Business and Software Development
  • Wayne Loyd / CEO of Smarter Contracts / Marketing

Community team members

flat structure, scaling with supply

  • Development (40% optimally)
    • C++ Developer (EOS dev., git dev.)
    • GUI developer / UI/UX master
    • Frontend Web dev. (HTML5/CSS3/Angular6+)
    • Backend Web dev. (Python/Django/Storage)
  • Deployment / Administrators (5% optimally)
  • QA / Testing (15% optimally)
  • Marketing / Sales (20% optimally)
  • Community Support / Social Moderators / Help Desk / PR / Ambassadors (20%)

Hired or outsourced Staff

As long as needed, to be migrated to community team members with time

  • Deployment and System Administrators
  • Marketing / Sales
  • Helpdesk / PR
  • Accounting - looking into 100% automagic here


Whitepaper v1.0

2017-09-01 08:00 UTC, with in-house 3-layer blockchain concept, calculations, done

Logo Designs, design style

2017-10-01 08:00 UTC - 2018-04-24 08:00 UTC, 3 iterations, now final

Marketing materials

2018-02-09 08:00 UTC - ongoing

Whitepaper v2.x

2018-02-26 16:00 UTC, in-review 2.0

2018-04-02 16:00 UTC, in-review 2.1

2018-06-26 12:00 UTC, 2.2, Knife overhaul, more fixes

2018-07-09 12:00 UTC, 2.2.2, online version live

2019-03-12 17:00 UTC, 2.2.5, MBI information updated into the Whitepaper

2019-09-10 12:00 UTC, 2.3, removed git repository service fees, major update provisioned

2019-10-25 11:00 UTC, 2.3.1, updated everything according to recent developments, including tokens, MBI, revenue share, and many technical aspects including fragmented git storage node

Website Launch and Updates

2018-03-19 08:00 UTC v0.1

2018-04-24 08:00 UTC v0.2 EOS Hackathon Edition

2018-07-09 12:00 UTC v0.3 EOS Independance Day Edition

2018-09-24 12:00 UTC v0.4 Roadmap updated with MBI

2018-10-14 12:00 UTC v0.5 Infrastructure update, survey added

Milestone Based Issuance

2018-09-24 12:00 UTC - 2019-12-13 12:00 UTC: Development

Development of codum - the code market

12 months from the date when initial funds required to start the full scale development process are secured

Launch of the initial codum.io platform

6th month in development: testing / developer access / first revenue

12th month in development - public launch of initial codum.io for business, covering these features:

  • Secure interface to existing git repositories
  • Public metadata of git repository
  • Licensing and license templates
  • Knife across repositories covered by codum
  • Project management and git access UI, including code review
  • Licensing and Account management UI
  • Sourcing contracts with implemented simple configuration UI

c_ tokens become traded on exchanges

exact exchanges and dates to be announced

Feature Development, Post-Launch maintenance

from launch date indefinitely

Decentralization achieved by codum community

4th year post launch - company running codum development and maintenance is doing so as part of the codum community. Control of the source code, governance and legal are completely decentralized across the implemented decentralized governance structure.