MEV takes two predominant forms as of Jan 2023 — front running and sandwiching. Both of these algorithms rely on the public nature of the pending transactions in the mempool and their interaction with a DEX and specifically the Automated Market Maker (AMM) logic. This typically involves a user making a swap on the DEX, say (WETH for WBTC on Uniswap). Because the purchase will raise the price of WBTC due to the way the AMM works, a miner who is listening in on the mempool can identify the trade and then insert their own WETH/WBTC buy order right before the victim’s trade, then insert their sell order right after the victim’s trade. Assuming sufficient gas is remaining in the block, this is a riskless arbitrage and the victim paid a higher price than they would have if not for the MEV user. Highly centralized ecosystems have emerged on several blockchians which seek to address this issue, with varying degrees of success. However none of them are in-protocol or on chain as of the writing of this article.

There are two main schools of thought on how to address MEV: forced ordering of transactions and transaction hiding.

Idea #1 involves forcing an order of transactions based on a non-deterministic and unknowable identifier. This requires a two step process where the block is first assembled, the hash is created and then the block is reordered based on the hash or some other random data. For sandwiching, this means that it’s still possible, but the MEV user only has a 1/6 chance for the order of the execution to occur correctly — e.g. all three transactions have to come out as: MEV buy, victim buy, MEV sell. Any other order results in failed transactions and lost gas or even a loss by the MEV user. For pure frontrunning the MEV user has a 1/2 chance for the order to come out correctly, which could be net positive depending on the trades. So, re-ordering doesn't fully address the issue in the context of DEX trading and doesn’t cover other kinds of front running like NFT sales, lotteries, online games, etc.

Idea #2 is more complex, but does fully address all MEV attacks. This involves encrypting the transaction in the mempool upon submission, so that miners do not know the contents of the smart contract execution instruction. Encryption eliminates any “unfair” optimizations on a DEX, NFT marketplace or anywhere else. The miner simply doesn't have the information to take advantage of. Of course the transaction needs to be decrypted to execute the contracts in the block, however that does not happen until the POW puzzle is solved. In this design, the smart contract execution is encrypted in the wallet and sent to the mempool. Symmetric encryption is used with a one-time random key. The key is released via a gossip protocol some number of seconds after the transaction, which is then broadcast throughout the network. Miners can attempt to wait for keys before assembling a block, however they will be at a very significant disadvantage and likely lose most or all block rounds. After assembling the block of encrypted transactions the miner submits it to the full node for acceptance to the chain. Everything is pretty much as-is for a standard POW chain. The second step involves stakers decrypting and processing the blocks. Because Dynamo will be a hybrid POW/POS system, it is uniquely positioned to leverage stake operators as smart contract executors. As staking full nodes ingest new blocks, they will be tasked with decrypting and executing the contracts in the prior blocks.

Smart contract execution results in two general categories of updates: internal state update and external coin transmission. Internal state update occurs when the contract updates a stored value in the contract or accepts coins sent to it. An example would be when a user sends coins to a deposit contract which then stores the value of the coins for future use. External coin transmission occurs when a smart contract sends coins to a target address.

The internal state of smart contracts will be stored on staking nodes. Nodes will be responsible for keeping track of all smart contract balances and internal variables. Transmission of coins from smart contracts will be handled by miners when generating the coinbase transaction. When smart contracts determine that coins must be sent, entries will be generated in the mempool by staking nodes which miners will receive when solving the POW block. These special transactions will be generated by miners as a coinbase output.

Consensus on smart contracts will be maintained so long as 2/3 of the staking nodes, by staked coins, are honest. Sybil attacks are not possible, because the weight of a single node with 1,000 coins is the same as 1,000 nodes with 1 coin.

As each full node receives new blocks, the transactions in the block will be decrypted and executed in the order they are mined in the block. If a decryption key has not yet been received, the full node will wait for at most one more block before discarding the transaction. Disparities may arise in the number of transactions which were processed by full nodes, which can be resolved by consensus based on the number of smart contracts processed in a block (block with the most number of smart contracts executed becomes the winner), however all contracts must be executed within 2 blocks of being mined, so transaction submitters have an incentive to timely submit their release keys to have their smart contracts included in the chain.

This design attempts to account for all possible DOS attack vectors, however there is inherent complexity in any smart contract platform, and in particular, a smart contract platform based on a bespoke hybrid POW/POS system. Comments, thoughts and critiques are always welcome on our Discord at https://discord.gg/PxXxh8tGKj

Peer to peer online marketplaces abound. Some are semi-decentralized, such as Craigslist or, arguably, Facebook Marketplace. These platforms merely provide a platform for buyers and sellers to connect, but no other services. It is up to the participants to verify the quality of goods, exchange payment, arrange delivery and resolve post sale discrepancies. Other platforms are fully centralized, like Ebay, Etsy and Mercari. These platforms handle end-to-end transaction flow with full identity verification and dispute resolution mechanisms. Marketplaces are not limited to goods; platforms for various services exist as well in varying degrees of decentralization: Fiverr, Upwork, AirBNB, Uber, Lyft, Angie’s List, Zillow, etc. The common theme behind all of these marketplaces, whatever their level of decentralization, is that there is a single entity in between the buyer and seller. That entity may or may not directly profit from the transactions which they facilitate, however all do profit in some way, if even indirectly.

Let’s imagine a new platform, totally decentralized, with no entity at all in between the participants. The platform is run by unaffiliated third parties, spread across the globe, none of whom know or trust each other. Listings can be placed by anyone, anywhere, totally anonymously and without review or censorship of the content posted. Buyers can view listings from anywhere and when a purchase decision is made, make immediate, anonymous, guaranteed payment. The payment can never be reversed by a third party and its release can be triggered by a time delay or some external event. Isn’t that what cryptocurrency promised us? Sounds promising, yet scary.

The above proposal is technically possible. Fullnode operators of a crypto chain can agree to servers that exchange seller listing data over peer to peer connections and host listing search services so buyers can find what they are looking for. Buyers can connect to the chain with a client, or run their own fullnode if desired, and search for listings, make offers and send crypto payments to sellers. All of this is secured by a decentralized, autonomous chain of third party miners and/or stakers who have no interest or gain from the transactions occurring on the network.

Just because it’s possible, does that mean it’s good? Not really.

The first obvious abuse of this system is the sale of illegal or unethical goods and services. Sales of firearms, revenge porn, stolen identities, child trafficking — the list of potential abuses of this marketplace is long. The listing of those kinds of items needs to be suppressed somehow, both to protect victims and the operators of the network over which those listings are flowing. The suppression mechanism needs a score system to avoid spam from attackers suppressing everything. The mechanism should also have some “trusted list” based on a published identity that fullnode operators can validate — for example, major media producers who want to protect their copyright information can publicly announce their source address for suppression notices and then monitor for violations. The same would apply to global law enforcement. Fullnode operators can then decide which subscriptions they want to connect to for suppression based on their own local legal jurisdiction, tolerance for legal peril or personal ethics.

Regarding spam, there should be a mechanism to “charge” for listings, lest malicious actors attempt a denial of service attack on the network by listing 1,000,000 rolls of toilet paper for sale over the course of a couple of seconds. However the listing fee should not go to anyone, for fear of that person or entity being classified as a broker by the relevant authorities and thus subject to myriad reporting requirements. To eliminate any connection between market participants (buyers and sellers) and market operators (fullnodes, miners, stakers), the fee paid by sellers should just disappear (e.g. be sent to a burn address or similar). Similarly, the ability to bid or purchase should result in the need for immediate payment or escrow to prevent spammers from bidding on or buying every single item for sale and then simply not paying.

One critical role that marketplaces play today is being the first arbiter of disputes. Peer to peer transaction issues abound. Purchaser didn't receive the item — was it shipped incorrectly or lost by the post office? Purchaser got the item but it doesn't work — was it working when it shipped and the purchaser broke it or was it DOA? For service based goods the issues are even murkier. The web developer did a bad job — was the developer truly incompetent or were the requirements given by the client a total mess? This issue has two potential solutions as I see it:

1 — Use the marketplace for low effort, low risk or low price items only. You pay $10 for your Funko Pop piece of plastic junk based solely on the sellers rating or other out of band verification that you perform. If it ships and arrives in good shape, fine. If not, you are out $10. Same with services — only contract what you are able to lose — so only small, one-off jobs get contracted. All the verification and dispute resolution is left to channels outside the marketplace. Payments are sent immediately or perhaps held for some number of days and then automatically released. Although simple, this strikes me as less than useful to the general consuming public who want to transact with each other.

2 — Create a built in dispute resolution service for larger jobs/sales. For example, market participants can agree to some international dispute resolution process (e.g. JAMS) via autonomous electronic contracts. For large service based projects, milestones can be created based on timeframes or information deliverables (e.g. github commit, document upload to Google Drive, etc.) and if those milestones are not met, then arbitration mechanisms trigger and the case is automatically sent for dispute resolution. The seller or vendor can be required to post a small bond up front to cover the cost of the dispute resolution service, which would be released to the buyer to cover the costs of initiating the dispute resolution. Conversely if the vendor is initiating the dispute, some amount of the buyer’s pre-paid escrow can be released to the seller/vendor to cover the costs. Although more complicated, this more closely tracks what current platforms implement, e.g. Ebay, Upwork, etc. Reality is that current marketplace dispute resolution which is administered by the centralized platforms is nearly non-existent because they always resolve in favor of the buyer. Anecdotal social media postings overwhelmingly confirm that platforms cater to those who are giving the money, not those who are rendering services or selling goods. So this solution is moderately better because it at least escalates to a known neutral at the outset of the dispute.

Listing hijacking is a common problem which I have personal experience with. A couple years ago I listed a light duty lawn mower for sale on Ebay for about $1500. Shortly after the listing, three other listings were posted with the identical picture, at about half the price. One of them was listed in the UK but they forgot to change the verbiage which offered “free delivery to 50 mile radius” of my town in Pennsylvania. Comical, but annoying. I received several DMs from Ebay users alerting me to the listings, which I forwarded on to Ebay. Unsurprisingly, no action was taken by Ebay on any of the fake listings. I began to check other listings, particularly my GPUs for sale and found many of those had been cloned as well, sometimes more than 10 copies existed. These were not stock pictures; they were pictures of the actual card, with serial number, sitting on my kitchen counter or wherever I had happened to take the photo. Ebay obviously lacked any procedure for detecting even a modicum of fraud being committed. This is likely why they side with buyers in all cases, so they can be lazy on detecting fraud by sellers.

In a decentralized environment, with no Ebay to be lazy in between, this becomes even more difficult. It could be possible to use some AI to detect image copies and flag potential fraud to buyers. However, deepfakes, procedurally generated images and simple photoshop jobs all plague the marketplace. A mechanism needs to be developed to deal with fake listings generally, however it’s unclear to me how this could be crafted.

Review bombs and review purchasing are another issue. For example, Steam has been exploited by its own clients who wish to make political statements. Users will loosely band together to “review bomb” a game by a publisher whose content the user group feels is offensive or if the company has engaged in some unpopular activity totally unrelated to the game. Fiverr, Trust Pilot and Google Reviews are notorious for purchased positive review services. A simple search on Fiverr for “reviews” will yield multiple sellers willing to harvest positive Google reviews for a fee. Overcoming inauthentic reviews is extremely difficult and may have no possible solution. In a decentralized platform it becomes even more difficult to know who is a verified purchaser leaving a positive review for a seller. In fact a single entity can create thousands of wallets and listings, posing as a whole marketplace themselves, creating tens of thousands of listings and purchases, all in a grand charade to boost their own score with no actual transactions occurring. A coordinated effort over some medium period of time (say, a couple months) could allow a single person to game the whole system and then profit by exploiting the accounts themselves or selling them off to fraudsters. If highly centralized, well funded corporations cannot adequately control review/score manipulation, it seems unlikely that a decentralized solution can be crafted.

Seller impersonation and general identity issues pose another problem. A decentralized platform provides a unique avenue for the use of stolen identities, because victims have no one to complain to. Let’s assume for a moment there is some way to confirm the identity of a single person in a decentralized and trustless way (more on the issues of that below). Lets say I upload some kind of identity documents to a local program which creates a hash that proves something (it knows I uploaded a valid California Driver’s License, just not which one). I then use that ID hash as my online marketplace identity — people know that I am “someone” just not exactly who I am. Now my identity is stolen and the hacker proceeds to list many fraudulent listings, collecting payments and never delivering goods. As the victim, who do I file the fraud report to? Can I simply mark my record as fraudulent and then the network will no longer transact on my ID? Spammers could then mark all current users as fraudulent to cripple the marketplace. There needs to be some offline way to validate a user such that their identity is never exposed, and a way to revoke that identity, only by them, in a trustless and decentralized way.

Assuming that a “trustless ID” could be created — e.g. I know that a hash is a real person, I just dont know who that person is — would people use it? Imagine the fear of the common user taking a picture of their driver’s license and “uploading” it somewhere, which is supposedly safe. The consuming public has been bombarded with hack after hack of wallets, exchanges, lending platforms, etc. Are people really going to understand that a local executable wont transmit their data somewhere? Who would host and verify this executable?

Let’s say that an accurate, trustless ID system could be built, and people actually did use it, and then buyer and seller trust scores were created based on transaction history. What legal responsibilities would fullnode operators bear to their users? If a buyer unfairly rates a seller poorly, who does the seller complain to? If someone programmatically gives themselves thousands of positive reviews, how do market participants know? Do fullnode operators become liable for known inaccurate data which they cannot themselves remedy? Are fullnode operators complicit in fraud committed by users on the network if they know fraud is occurring but have no power to stop it?

The problem with DNS: any system which relies on the standard DNS system is centralized by definition. It will be subject to censorship by ICANN or the hosting entities (Godaddy, AWS, Azure, Comcast, etc). It could be possible to create a new TLD, however that would itself be subject to the DNS consortium rules and subject to censorship by major browser producers who could simply not trust the chain certificate. This is also costly ($150,000 application fee as of the time of this article). Users could be required to download a supplemental TLD file and install it to their browser (bypassing many security warnings along the way). This would create huge barriers to usage. So either the system must be based on a non browser based solution (e.g. download a fat client similar to QT based wallets) or the system must allow browsers to connect to fullnodes via IP or perhaps proxy gateways. (something like onramp.mymarketplace.com) However, those gateways may be subject to censorship by service providers. The fundamental tension between easy to access and non-centralized creates a difficult and perhaps unsolvable problem.

Would fullnode operators be responsible for the content they pass along? Similar to website operators today, disinterested content hosting entities are generally not responsible for the content they host (in the United States) so long as they promptly respond to takedown requests. We can thank Section 230 of the CDA for that. Some jurisdictions, notably the Ninth Circuit, are starting to chip away at this, particularly if platforms encourage users to engage in illegal activities or the thing that the platform does actually enables illegal activity. Lemon v Snap is one example. However, fullnode operators would be nothing more than a mini-ebay in this case, simply hosting information and passing it along. As long as fullnode operators respond to any takedown suppressions they would be functionally equivalent to a bulletin board operator and should enjoy the protections offered by Section 230.

The final thought I will present — can this system be used for money laundering? Any system which could be viewed as an attempt to subvert KYC/AML laws could gain unwanted attention of the authorities and subsequent sanctioning (e.g. Tornado Cash). Although the system presented here is far more decentralized than Tornado Cash (which in reality was totally centralized), the concept could potentially be subject to sanction, or perhaps even the entire chain. Sanctioning the chain entirely would be a draconian step, akin to sanctioning Ethereum because it enabled Tornado Cash to exist in the first place, so I see that as unlikely, however it still should be considered in the overall design. Sanctioning the system could be possible, although its unclear what exactly would be subject to the sanction. “Anyone who uses mymarketplace” would be considered in violation of US Treasury laws? Arguably, Facebook Marketplace and Craigslist could be lumped into this group, as the platform has no meaningful identity verification process required before using the marketplace feature. More centralized platforms like Ebay, Etsy and Mercari require connection to a bank account to obtain funds and thus are already under KYC and SARS reporting regimes in the United States.

What would prevent someone from selling a pillow for $10,000 (in crypto) and using illegal funds to purchase it in an anonymous way? Not much. NFT marketplaces are already under scrutiny for this type of transaction. What prevents someone from doing that now on any number of other platforms that only facilitate buyers and sellers connecting but do not actually transact? The key difference here is that the system -would- allow the peers to transact, and thus lies in a gray area. One could argue that the laundered funds are still in crypto and thus need to touch an exit point on an exchange, at which point the requisite AML/KYC should occur. Fullnode operators need to be aware that they are potentially assisting criminals with money laundering, however that seems no different than fullnode operators on Bitcoin and Ethereum today. The extra layer of a marketplace shouldn’t make a difference but some regulator in some jurisdiction may not understand the difference or may not agree.

The promise of a totally peer to peer marketplace with no intermediary is enticing. Sellers no longer pay exorbitant fees to Ebay. Vendors no longer pay 20% of their earnings to Fiverr or Upwork. However, the path to an open, fair, honest and legal network is fraught with peril. The technology is ready; the devil lies in the details of process and compliance.

Batching of staking payouts

Initial simulations of staking reward payouts demonstrated a potential DOS attack vector which needed to be addressed. Specifically an attacker could stake millions of (presumably small) balances resulting in a transaction flood at the end of each staking epoch. This could effectively halt all transaction processing by creating blocks larger than the current allowable size (10mb).

The initial design called for full nodes to calculate and automatically pay out staking rewards within certain block times after the staking epoch. This was changed to requiring stakers to claim payouts and then having full nodes validate the staking claim. Instead of batching all payouts in a single block, payouts will be spread out based on mempool processing capacity, which is automatically moderated as part of normal BTC core operations. This change addresses both the transaction batching and block size issues using already built core mechanisms.

Finality of staking rewards for consensus

A consensus design issue was identified in the staking ticket processing logic. A race condition could exist where different honest nodes could determine that some staking tickets were invalid, resulting in an improper hard fork and eventually pruning from the network. This was particularly acute during fullnode restart intervals. The original design called for storage of pending rewards in a local database during the staking epoch and calculation of rewards based on that local database after a cooldown at the end of the epoch.

The revised design eliminates the local database for pending rewards and instead uses the historical blocks stored in the fullnode for the best chain tip, after a cooldown at the end of the epoch. Although this puts additional processing demands on fullnodes it is the safest and most secure method to calculate epoch staking rewards in a manner which will never break consensus.

Handling intermittently offline staking nodes

An issue was identified regarding the processing of incoming blocks and the storage of staked amounts and pending rewards during initial block download after the restart of a fullnode. The original design called for processing all incoming blocks as they arrived from other nodes and then building the pending payout database and staked balance database. As noted above the pending payout database design as abandoned. Additionally the staked balance database was re-designed to recalculate all staked balances after initial block download was complete, including during a restart of an existing partially in sync node.

By re-calculating all staked balances after IDB, the staked balances are guaranteed to be correct at the time of staking payout calculation, eliminating issues of possibly incorrect balances and thus inaccurate payout calculations leading to consensus breakage.

Revised development timeline

Based on the technical issues encountered, development is approximately 3 weeks behind the initially published timeline. Proof of stake implementation on mainnet is now estimated to occur in early to mid September 2022.

On Saturday June 11, 2022, Discord credentials for the owner of the Dynamo Discord server were compromised which resulted in the Dynamo Coin Foundation’s loss of control of the server. Community members quickly worked together throughout the day to restore the community in a new Discord server. As of the writing of this article there were no known direct financial losses associated with the security event.

Timeline

At approximately 3:30pm eastern on Friday June 10, 2022 a social engineering attack was initiated against the owner of the Discord server. The attack originated from a trusted individual whose account had been compromised. Using that individual’s DMs the attacker was able to create a detailed narrative including using a shared Google Drive link which was password protected that the target had used with the individual previously.

At approximately 4:30pm eastern the malware payload was transmitted to the target however it was not immediately executed.

At approximately 3:30am eastern on June 11, 2022 the malware was executed on the target machine and the target’s Discord credentials were compromised, however it was not readily apparent. Although the target’s Discord had 2FA enabled this was circumvented by the malware which is a known exploit on the Discord client. The target’s machine was powered down shortly after. No credentials related to Dynamo Coin were entered into the computer at any time after the compromise.

At approximately 9:15am eastern the target was contacted by several individuals indicating that they had been targets of hacking from the target’s Discord account.

Actions we took

As soon as the compromise was discovered the Dynamo Foundation team began coordinating with the community to mitigate damage to the project.

Although the Discord credentials that were compromised were not shared with other accounts, the Dynamo Coin Foundation took several precautionary steps:

> All AWS console passwords were changed. 2FA has always been enabled.

> All AWS Windows instances administrative passwords were changed.

> All Ubuntu port 22 access was revoked if open

> All Metamask/BSC wallet keys were rotated

> A review of all relevant DMs with the target’s account was performed and messages were deleted

> The NFT and Discord wallet bot servers were shut down

> Security breach reports were filed with Discord and associated bot developers

> All references to the old discord links were changed on all socials

> Social announcements were promptly posted informing the community of the hack and directing people to the new Discord community

> The owning account of the new Discord server is a “break glass” account which will not be used for any purpose and all communication with that account will be ignored

>The target’s infected computer was destroyed including motherboard, all GPUs, m.2, keyboard and mouse.

What we will do going forward

Lack of support from Discord is a significant security issue. The inability to get real time support for a security breach is an unacceptable risk. Accordingly we will cease any reliance on Discord for any internal technical communications, especially DMs. The use of a break glass account as the server owner should mitigate the risk of losing control of the server again, however that is no guarantee.

We will institute a policy that no executable can be installed from any location other than the public Dynamo github repo.

Dynamo coin technology assets will be airgapped from personal computers for Dynamo developers.

Dynamo coin will investigate and implement a chain based chat mechanism which will use private key encryption and full nodes as relays in order to eliminate reliance on Discord, particularly for important community messages.

Conclusion

The Dynamo Coin Foundation takes full responsibility for this security breach and will reimburse any entity which suffers financial loss as a result of it. Security incidents are a fact of life, however it is important to learn and evolve when they do happen. In May 2022 there were 70 reported Discord server takeovers of NFT projects alone, including notable companies like OpenSea and Bored Ape where users experienced significant financial losses. Discord is clearly a large and vulnerable attack surface.

Discord is a prerequisite for any modern crypto project. Community members expect that projects will have either a Discord or Telegram group where they can get updates and contribute to the conversation. In this context, it is a necessary evil with significant security risks that need to be actively mitigated. The Dynamo Coin Foundation will continue to support a Discord group, however we will reduce our reliance on it by creating alternate, parallel technologies that enhance the security of the community and remain true to the decentralized nature of the project.

Dynamo Coin is backed by a group of technology professionals who are committed to the continued success of the project. The robust community includes many vested entities who are here for the long term. Although this incident was disruptive, the blockchain technology remains entirely decentralized and was not impacted in any way which is one of the core promises that Dynamo, and blockchain generally, strives to deliver on.

Modifications are required to three components of the Dynamo ecosystem: the full node, the miner and the web wallet API. An additional new fourth program will be developed to allow QT wallet users to stake and unstake from a command line utility. It is not currently planned to modify the QT wallet GUI to allow for staking, however anyone is welcome to do so.

Following is a tentative timeline for development:

> Finalize technical spec: June 13, 2022

> Complete modifications to full node: June 24, 2022

> Complete modification to miner: July 1, 2022

> Complete web wallet API and command line utility: July 8, 2022

> Deploy operational testnet: July 11, 2022

> Upgrade mainnet: August 15, 2022

Although no issues are currently expected, the above timeline could be delayed due to unforeseen technical issues discovered during development.

Starting in the next couple days, mainnet github repos will begin to have updates related to this development and will therefore be unstable / experimental. As always, only release tagged builds should be used for fullnode or miner deployments.

The Dynamo Foundation will provide frequent updates on the progress of development and will seek community help with launching and verifying testnet and ultimately transitioning to mainnet.

The goal of the Small Coin Association is to assist small market cap cryptocurrency projects though shared learnings, pooling of resources and member vetting to provide investor confidence.

By establishing a rigorous entrance criteria, the association members will create value in the ecosystem and build trust with users and investors.

Membership

Membership is limited to projects which have less than 10 active developers and a 60 day average market cap of under $10,000,000 USD.

Member projects must have a mainnet coin with a public github repo. No tokens, NFTs, contracts, etc. will be admitted.

Member projects must be at least 1 year old.

Github commits must be recent and frequent. Exceptions may be made for projects which have gone dormant and are restarting.

Project principals must be fully transparent about their identity and background including linkedin profiles or similar.

Project principals cannot have been associated with prior rugpulls, scams or fraud of any kind.

Projects must have crypto programmers on staff, either as founders or contractors/employees. The core focus of the project must be development oriented and not simply hype marketing or other non-technical activities.

Projects should have some social presence (even if small). Projects must be willing to cross-promote other member’s projects to their audiences.

Principals do not have to be working full time on their projects, but should have regular engagement and updates.

Projects should have a clearly articulated roadmap and/or whitepaper which sets forth the project’s goals and timelines.

Activities

Members will gather periodically to discuss current events, crypto trends, technical challenges or other issues relevant to mainnet crypto currencies.

Members should be willing to help other members with development activities including making pull requests, assisting with infrastructure issues or other technical assistance.

Members may pool funds to engage in group marketing, e.g. splitting the cost for and influencer to interview some members or promote the association as a whole.

Members may coordinate investment opportunities, such as creating an index fund of the member’s coins for offer to investors.

Balances for voting purposes will be frozen as of block 1,562,000. Each address will have a snapshot balance which represents the voting power for that address. Users should acquire whatever coins they want for voting purposes prior to this block number. Note that there is no mechanism for users to vote exchange held coins because the exchange holds the private keys, so coins which are held on exchanges which users want to vote need to be withdrawn.

Voting period

The voting period will last for approximately 10 days. During this time users may cast their vote, at any time after block 1,562,000. Votes must be cast up to and including block 1,600,000. Any vote cast on block 1,600,001 or after will not be counted. The casting of the vote occurs on chain as documented in the UTXO voting mechanism technical paper. Open source versions of the command line voting utility and the web wallet voting code will be made available. Coins in non-custodial wallets, such as those held in games or discord wallet, can be voted via a web API.

Hash to vote

The proposal hash to vote will be :

15d195feb0ed2e6ed0bc0ea12a13c82f0a28ecd88aae8f09a7fc34df1c8fcd55

This is a random hash because the vote is non-binding and doesn't involve a specific proposal.

Voting options

The vote submitted is the user’s preference for the % of split for proof of work. The options are: 70, 60, 50, 40, 30.

For example, a vote of 70 means 70% proof of work reward, 30% proof of stake reward.

Votes which are not one of the above options will not be counted.

Step 1: Announcement of voting

The proposer of a vote should mine an NFT with all required documentation to detail what the proposed action is. This may be in any format, such as PDF, text, PNG, etc. The proposer may mine multiple NFTs if required. If there are multiple NFTs required, the proposer needs to select a “master” NFT which references all other NFTs in the proposal.

The proposal should minimally document:

1 — The start of voting blockchain snapshot, which should be at least 10 days in advance of the announcement, but can be any time. The proposer is responsible for garnering enough interest to pass their proposal, so an adequate timeframe should be selected.

2 — The master NFT hash which documents the proposal

3 — The voting threshold required to pass — 85% for a change to consensus, 75% for a change to the rules, 66% for anything else

4 — The voting period, expressed as a number of blocks

5 — The TXID of the mined vote proposal

Vote proposal are mined into the blockchain by sending an OP_RETURN transaction with the first 4 bytes of 0x01000000 followed by the hash of the master NFT that documents the proposal.

Step 2: Blockchain snapshot

At the designated height, the balance of every address is recorded. This is the voting power of each address for the voting period. Any user can create and verify their own snapshots for audit purposes.

Step 3: Voting

Voting proceeds during the voting interval. Votes are cast by signing a transaction and having it mined into the chain.

To cast a YES vote, the user should sign an OP_RETURN transaction with the first 4 bytes of 0x02000001 followed by the TXID of the mined vote proposal followed by the user’s address containing the coins to vote.

To cast a NO vote, the user should sign an OP_RETURN transaction with the first 4 bytes of 0x02000002 followed by the TXID of the mined vote proposal followed by the user’s address containing the coins to vote.

Support for “multiple choice” type voting could be extended with opcodes like 0x020000nn.

Users are responsible for the transaction fees associated with submitting the voting transactions. As of the time of this writing those fees would be 0.0001 DMO per address per vote.

If multiple votes are cast for the same address only the latest vote is counted.

Votes cannot be withdrawn.

Step 4: Tabluation

Votes are tabulated by summing the snapshot coin balances in wallets which voted YES and NO. The % vote is the total number of coins voting yes divided by the total number of coins that were voted. The % must be greater than or equal to the threshold in order to pass the proposal.

Purpose/Incentive

Implementing Proof of Stake on the Dynamo Coin Mainnet will create economic incentives to acquire and hold coins for future value and returns.

A Hybrid Proof of Work / Proof of Stake model is more secure and less centralized than a pure Proof of Work or Proof of Stake coin.

Proof of Stake node operators enhance the security and robustness of the network by operating full nodes.

Economics

Currently, the block reward for proof of work miners is 1.0 DMO per block. This proposal modifies that to 0.6 DMO to miners and 0.4 DMO to a staking pool. The staking pool is awarded to stakers based on the schedule below.

Stakers may choose to stake any amount of coins.

Stakers must be running a full node to claim staking rewards.

There is no slashing, however stakers which do not claim their rewards timely lose the ability to claim them.

Stakers must stake for a minimum fixed period of time: approximately 30, 60 or 90 days, equivalent to 130,000, 260,000 or 390,000 blocks. The actual lock time is measured in blocks based on the block when the coins were staked.

Coins can be unstaked at any time. If coins are unstaked prior to the reward block, then all pending rewards are forfeit. If coins are unstaked after the reward block, rewards can continue to be claimed at the current rate.

The pool weighted earning rate for staking is 1x coins for 30 day tranche, 3x coins for 60 day tranche and 6x coins for 90 day tranche. A person staking 600 coins for 30 days will earn the same pool % as a person staking 100 coins for 90 days.

Staking is accomplished by sending coins to a burn address with a designated OP_RETURN code, which will flag those coins sent as staked in the given tranche. Unstaking is accomplished by sending a small transaction (e.g. 0.0001 DMO) to a burn address with a designated OP_RETURN code.

When coins are sent to the staking address, the TXID of that transaction is used as the stakers’ voting ticket.

After the generation of each block by the proof of work miners, current stakers will be eligible to submit voting tickets on that block as it is replicated. Stakers must submit staking tickets within 10 blocks of being eligible. Staking tickets submitted after 10 blocks will be rejected by the mempool. A staking ticket submission consists of a coinbase transaction claiming the number of staked coins in a particular tranche.

A staking ticket will increase the total work of the chain, thereby increasing the chance that chains with more honest votes will become the main chain.

Stakers will be self-selected using a pseudo-random hash based on the current block hash and the 20 most recent block hashes. The selection hash is based on the current block hash which is hashed with the 20 most recent block hashes and then logically XOR’d with the staker’s TXID of the claimed hash. If the resulting hash mod 256 = 0 then that ticket is eligible to claim a stake for that block.

Stakers may stake as many different times as they like. Each TXID will be independently eligible for a reward.

Staking rewards are calculated every 1000 blocks. Rewards are calculated as the proportional amount of coins staked times the number of tickets claimed times the amount of block rewards during the reward cycle. Calculated rewards are paid at the end of the staking cycle unless coins are unstaked in which case all pending rewards are forfeit and burned.

Example:

Staker A stakes 2,000 coins on block 1,400,000 for 130,000 blocks (30 day)

Staker B stakes 1,000 coins on block 1,425,000 for 260,000 blocks (60 day)

Staker C stakes 1,000 coins on block 1,450,000 for 130,000 blocks (30 day)

For block rewards between 1,400,000 and 1,500,000 (as an example):

For blocks 1,400,000 to 1,424,999 — Staker A is the only person staking and thus receives 100% of rewards which is 400 DMO per 1,000 blocks or 25 x 400 = 10,000 DMO.

For blocks 1,425,000 to to 1,449,000 Staker A has 2,000 in the 30 day tranche and staker B has 1000 coins in the 60 day tranche. The pool weights are thus 2,000 for A (1x coins) and 3,000 for B (3x coins). A will receive 40% of the block rewards and B will receive 60%. [2000 + 3000 = 5000 … 2,000/5,000 = 40% and 3,000 / 5,000 = 60%].So for these 25,000 blocks, there will be 400 DMO per 1,000 blocks, so Staker A will receive 400 x 25 x 40% = 4,000 DMO and Staker B will receive 400 x 25 x 60% = 6,000 DMO.

For blocks 1,450,000 and beyond, there are three Stakers — A with 2,000 in the 30 day, B with 1,000 in the 60 day and C with 1,000 in the 30 day. Total staking pool is 2000 (at 1x), 1000 (at 3x) and 1000 (at 1x) = 6000. So the rewards will be split 33% to A, 50% to B and 16% to C.

Rewards for A will begin being paid on block 1,540,000 for block rewards earned between 1,400,000 and 1,400,999 (e.g. 130,000 blocks after the expiration of the first reward period).

Implementation

Create two new OP_RETURN opcodes — stake coins and unstake coins

Create local database maintained by fullnode which tracks staking rewards

Modify fullnode to generate staking tickets for all coins staked by it

Modify consensus to adjust work based on POW hash plus tickets submitted

Modify accept to mempool to allow for staking coinbase transactions

Modify accept to mempool to reject invalid staking tickets

Modify miner to add staking coinsbase transactions into CB vout

Timeline

Testnet versions available approximately 2 weeks after voting on this proposal is complete.

Release to mainnet after 2 to 3 months of testing.

Voting

Ratification requires 67% of voting coins to enter proposal on a ballot

If put on ballot, the measure must have 90% of voting coins in favor to pass

Ratification ending block: 1,517,000 (votes to ratify must be cast PRIOR to this block). Votes will be tallied on block 1,517,500.

If put on ballot, ballot ending block: 1,562,000 (votes for or against must be cast PRIOR to this block). Votes will be tallied on block 1,562,500.

Ratification YES vote burn address:

Ratification NO vote burn address:

Ballot YES vote burn address:

Ballot NO vote burn address:

The next major upgrade for Dynamo involves implementing the hybrid proof of work / proof of stake security consensus algorithm. A hybrid POW/POS algorithm offers superior security to pure POW or POS alone while maintaining the decentralization that POS offers. The Dynamo whitepaper provides more details the economic and security reasons for implementing this feature, which can be found at https://www.dynamocoin.org/

The decision to proceed with implementation of this change will be voted on by the Dynamo coin holders in the near future. Below are the various parameters that need to be incorporated into the design.

POW/POS Split

As stated in the original whitepaper, the block reward, currently set at 1 DMO per block, will be split between miners and stakers. Although the white paper did not specify the exact amount, some original “tokenomics” documents referenced a 60% miner / 40% staker split.

Implementation Methodology

The POW/POS mechanism can be implemented using normal consensus methods, e.g. block acceptance by the chain, or via smart contracts. Smart contracts on Dynamo have not yet been tested and the testing is expected to take several months. Due to the upcoming implementation of ETH 2.0, there may be an opportunity to gain additional market share from ETH miners and having a staking option would likely be attractive. Therefore, it is preferable to implement staking as part of the consensus mechanism and not as a smart contract.

Staking Terms

It is desirable to allow for multiple “levels” of staking which provide greater benefit for longer staking terms.

As an example, if the staking split is 0.4 DMO per block, then that could be further split into tranches, like 0.05 for 30 day lockup, 0.07 for 60 day lockup, 0.12 for 90 day lockup and 0.16 for 120 day lockup. Each group of stakers would be able to allocate staked coins to a specific lockup periods and then claim those coins at the end based on the accumulated rewards.

Slashing

Systems which provide for slashing invite centralization.

1 — Slashing due to nodes being offline or non-performant penalizes smaller stakers who cannot afford the infrastructure to maintain 24/7 connections and uptime.

2 — Slashing incentivizes full node operators to use hosted services such as AWS, Azure or GCD, leading to centralization.

Further, slashing that occurs due to a technical failure on chain or exploits requires community intervention to “fix” lost coins. This further centralizes the project.

Economic considerations

Staking dilutes the value of non-staker’s coins disproportionately, because new coins are being created and stakers get more of those new coins than non-stakers. This leads to an incentive to stake more coins which further limits supply and can cause artificial inflation.

By having a hybrid POW/POS algo, and limiting the staking reward to 40%, this impact is mitigated somewhat, however it needs to be taken into consideration in the final economic design.

Procedure

A staker will choose which tranche they want to stake to, for example, 30, 60, 90 or 120 days. In reality this would be block numbers (e.g. stake for 100,000 blocks), however days will be used for illustrative purposes.

The staker then sends their coins to a burn address along with identifying information about their node — probably a hash. This will be implemented as a specific NOP meta opcode.

The burned coins are recorded on chain along with the locking period.

Block mining becomes a two step process. First miners solve the nonce and submit blocks to the chain. Each new block hash generates a list of eligible nodes that can submit tickets to validate the block. A registered node must submit a ticket within some number of blocks (2 or 3?) to claim a portion of the reward for that block. This will be done by a NOP meta opcode and stored on chain.

At then end of the lockup period, the chain will automatically create coinbase transactions with accumulated rewards, proportional to the amount staked and number of tickets submitted, plus the original coins, which will all be sent back to the staker’s wallet.

Node operators may stake additional coins at any time and may stake coins in different tranches from the same node.

Node operators can run a pool by allowing others to stake to their hash and then allocating their proportional staking rewards to the delegated stakers. This allows for pooled staking.

Stakers can withdraw staked coins at any time, however all accumulated tickets will be forfeit.

Conclusion

Using this methodology Dynamo will offer multiple staking options which will increase security and create demand.