Ethereum Casper 101

jon choi
jon choi
Oct 22, 2017 · 25 min read

tl;dr Casper will implement proof of stake in Ethereum. We begin with a review on why proof of stake matters and continue with its strengths & weaknesses. This post aims to provide a broad overview of Casper and clarify some of the confusion with respect to the two protocol design efforts related to Casper. The two proposed implementations share the same core design principle: applying cryptoeconomic mechanism design to secure the network while managing challenges regarding liveness, safety and synchrony assumptions. This post is also an overview of the progress so far and the challenges that lie ahead. Most importantly for fellow newcomers, the post identifies & defines key concepts and ties together various helpful resources under one context. The overarching intention is to make Casper and proof of stake more approachable to everyone in the community.

Enjoy and please don’t hesitate to reach out with questions, corrections or feedback (email, twitter).

Image for post
Image for post


  1. Proof of Stake
  2. A Tale of Two Caspers
  3. Why Casper Matters
  4. Design Principles
  5. Challenges
  6. Future Work
  7. Glossary
  8. Conclusion


While other posts, videos and papers focus on the specification, implementation and verification of Casper. This post focuses on the various guiding design principles of Casper, how it differs from competing approaches, why you should care about it, and how you can contribute to this project.

In addition, Casper has maintained an exceptionally open and collaborative culture among Ethereum researchers, developers and community members. I hope this post can continue that tradition by introducing you to Casper and convincing you why it’s important to Ethereum as well as the larger public blockchain ecosystem.

To summarize, this post is:

  • A quick and broad introduction to PoS and Casper.
  • Discussion on why Casper matters, its design principles and its challenges.
  • A list of key resources and terms to get you started with PoS and Casper.

This is not:

  • A full history of Casper.
  • Specification of Casper.
  • Implementation details of Casper.
  • Formal verification of Casper.

If this is review for you, a list of resources are linked throughout the post.

With that, I hope you enjoy this beginner-friendly introduction to Casper: Ethereum’s proof of stake research and implementation.

Proof of Stake

Proof of Stake (PoS) is a category of consensus algorithms for public blockchains that depend on a validator’s economic stake in the network.

In proof of work (PoW) based public blockchains (e.g. Bitcoin and the current implementation of Ethereum), the algorithm rewards participants who solve cryptographic puzzles in order to validate transactions and create new blocks (i.e. mining). In PoS-based public blockchains (e.g. Ethereum’s upcoming Casper implementation), a set of validators take turns proposing and voting on the next block, and the weight of each validator’s vote depends on the size of its deposit (i.e. stake). Validators are rewarded for their service to the network, but the stake also acts as an economic disincentive for bad actors.

Significant advantages of PoS include security, reduced risk of centralization, and energy efficiency.

Explicit Economic Security

On a related note, Vitalik further argues that PoS has better recovery properties. In PoW, there’s an issue of “spawn camp” attacks that can render a blockchain unusable. In PoS, the network can delete the attacker’s stake and prevent repeated attacks. The economic analysis further clarifies this concept. The marginal cost of repeated attack is the same as the first round in PoS. Whereas in PoW, the main marginal cost for another round during a 51% attack is the power cost (the incremental hardware depreciation & physical space cost is minimal for repeated attacks). To drive the point home, let’s paraphrase Vlad Zamfir, the cost profile of a repeated 51% attack in PoS is as if “your ASIC farm burned down” with each additional round.

Mitigation of Centralization

This means that two sets of mining pools with equal economic cost, one may be able to achieve a higher hash rate and have more influence in the network, dollar for dollar. For example, 10,000 miners that each spend $1/min ($87.6M/yr) may have less hashing power than one mining pool that spends $10,000/min (despite also spending $87.6M/yr). (Further work: quantifying the benefits to centralization in PoW mining would be fascinating. i.e. is it 1bps, 1% or multiples in hashing power per dollar invested?)

However, in proof of stake, a dollar is a dollar. The benefit here is that you can’t pool together to make a dollar worth more. Nor can you develop or buy application-specific integrated circuits (ASICs) to have an advantage technologically. So, PoS intends to mitigate the regressive distribution of PoW mining rewards and move directionally towards proportional distribution. (Going beyond proportional to progressive distribution will require mature decentralized reputation/identity management services).

Energy Efficiency

While Bitcoin may serve an important social function that may indeed exceed its financial costs and environmental externalities (i.e. Nick Szabo’s social scalability argument), proponents of PoS believe it is possible to replicate the incentive mechanisms of a PoW blockchain without wasting as much energy (by orders of magnitude). Alternatively, some may argue there exists a price of negative externalities where even the benefits of social scalability might be outweighed by the environmental costs.

While the exact answer is hard to ascertain a priori, I believe the crypto ecosystem as a whole has the responsibility to explore all promising consensus mechanisms to weigh their pros/cons and feasibility. (For example, it’s great that other projects are testing the benefits and feasibility of various forms of proof of storage, among others.)

Taking a step back, it’s also worth noting the two kinds of costs to PoW issuance. There are internalized costs, which are paid by miners and passed on to currency holders. Then there are externalized costs, such as the environmental costs and subsidies from governments (most likely in the form of cheaper electricity). In PoS, there are low consensus costs (no power & hardware costs), which allows for low issuance. As the network matures, it may even allow for negative issuance (net of burned tx fees as well as any penalties and slashing), which can have a price-stabilizing effect.

Therefore, not only is lower energy consumption better for the environment but it also enables simpler mechanism design. That is because lower energy consumption allows for substituting realized costs (power and depreciation costs are nonreversible) with potential economic value-at-loss (i.e. believable risk of unrealized costs) in order to secure the network. This is a key underlying hypothesis of PoS: both realized costs and prospect of losing money can incentivize participants to secure the network. Therefore–while difficult–it is possible (and thus preferable) to secure public blockchains via loss aversion, which can decrease the public costs and deadweight losses in a system.

Proof of Stake: Summary

So, now that we’ve discussed PoS, let’s dive into Casper.

Further Reading on PoS

A Tale of Two Caspers

Casper is not a specific implementation but a family of two main projects under active research by the Ethereum team. Informally, there’s “Vitalik’s Casper” aka Casper FFG and “Vlad’s Casper” aka Casper CBC (explained below). This subtlety isn’t clear until you start diving deep into Casper materials online, which can be very confusing to the “uninitiated.” (In fact, that is a main motivator for this post). While independent implementations, they have the same goal in mind: moving Ethereum over to proof of stake.

(Despite a surprisingly common impression that Ethereum is already implementing PoS, it is still a PoW chain (using ethash). While being memory hard and more ASIC-resistant than Bitcoin, Ethereum is a PoW chain nonetheless and has the same drawbacks with respect to energy efficiency.

So with that, let’s briefly discuss the two Caspers.


Casper the Friendly Finality Gadget (“FFG”) — aka “Vitalik’s Casper” — is a hybrid PoW/PoS consensus mechanism, which is the immediate candidate for Ethereum’s first bridge to proof of stake. More specifically, FFG implements a proof of stake mechanism as an overlay on top of a proof of work chain (such as Ethereum’s ethash PoW chain). Simply, the blockchain would grow every block with the familiar ethash PoW algorithm, but every 50 blocks is a PoS “checkpoint” where finality is assessed via a network of validators.

Casper the Friendly GHOST: Correct-by-Construction (“CBC”) — aka “Vlad’s Casper”—differs in approach from traditional protocol design: (1) the protocol is partially specified in the beginning and (2) and the rest of the protocol is derived in a way that is proven to satisfy the desired/requisite properties (typically protocol is fully defined then tested to satisfy the said properties). In this case, one way to derive the full protocol is to implement an estimate safety oracle (“an ideal adversary”), which either raises exceptions of a fault of a justified estimate or enumerates the potential future faulty estimates. More specifically, Vlad’s work focuses on designing protocols where one can extend local views of a node’s estimate of safety to achieve consensus safety.

Taking a step back, FFG focuses more on a multi-step transition to introducing PoS for the Ethereum network. This prepares for an iterative implementation that increases the role of PoS in the network over time. (PoS will claim a smaller portion of the rewards to start). In contrast, CBC focuses on formal methods that derive safety proofs “by construction” from first principles. Albeit confusing, the different approaches to solving this problem created two distinct work streams that complement each other well. The final form of Casper will likely draw from learnings from both FFG and CBC.

Next steps

In sum, both research projects are very active, and more updates should be available at Devcon3 in November. The role of this overview does not include going into more detail, but please feel free to dive into more implementation and design details in the links below (This doc will likely be updated or followed up once FFG and CBC papers are released).

Links for FFG

Further Reading on FFG

Links for CBC

Further Reading on CBC

Why Casper Matters

In simple terms:

  1. Decentralization (covered in PoS)
  2. Energy efficiency (covered in PoS)
  3. Explicit Economic Security (covered in PoS)
  4. Scaling Ethereum
  5. Gentle Transition from PoW

Because of Proof of Stake

As a review, (1) PoS has less available economies of scale because — “dollar for dollar” — a miner/validator can’t achieve outsized influence on the network. In PoW, a large mining pool might get more hashing power per dollar than an individual miner, whereas in PoS, a dollar is a dollar, which will likely mitigate the centralizing forces in mining.

And (2) whereas PoW relies on energy wastage for network security, PoS relies on the potential of losing a deposit for network security. The challenge then becomes (3) how we mimic (and enhance) the positive features of PoW and mitigate the weaknesses of PoS with economic mechanism design.

Because of Scaling

In PoW chains, finality is implicit (just as “skin in the game” is implicit via power wastage). The implicit nature of finality in PoW chains is apparent when you examine how transactions are finalized in real use cases. Depending on the magnitude and importance of the payment, you wait for additional number of block confirmations (number of block times since a transaction appears in the longest chain). For example, for a coffee, you might be okay with a few confirmations, but for buying a car, you may need more than the average number of confirmations.

In contrast, Casper provides a concept of explicit finality. For example, Casper FFG begins to overlay finality on top of the PoW chain. So the underlying chain continues to have an implicit way of determining how final a transaction is. However, Casper FFG provides explicit finality after about 2.5 “epoch times.” (Each epoch time being a sequence of 50 PoW blocks. A checkpoint is the last block in an epoch. It is first “justified” then “finalized” by a validator set. More details available in the paper linked above and potentially a future post.)

At that point, with certain Byzantine Fault Tolerance assumptions, we can be sure that either our assumptions have been violated or that the checkpoint is final. Since we are also aware of the validator set a priori (which can also be dynamic), bad actors are penalized through fault attribution.

So how does this relate to sharding & scalability? Having this explicit finality allows more flexibility in how much (more accurately, how little) each node in the network has to do. Having more regular explicit finality allows further exploration of questions such as: what if not every node had to hold all of the state or all of the transactions? what if not every node had to validate every transaction? These questions of having heterogenous “responsibilities” of nodes in public blockchains are tackled by a workstream around blockchain sharding.

So to go back to the point, if we are to explore each node in the network “doing less” or “knowing less,” it is hugely beneficial to consider only the past few epochs of finality rather than the entire probabilistic chain since the genesis block. Therefore, at this epoch time interval, finality doesn’t actually help with confirming a simple transaction, since transactions clear in number of confirmations fewer than the epoch time. Instead, finality will enable public blockchains to scale beyond the current ~10 transactions per second to larger orders of magnitude.

Because Ethereum is worth ~$28B

Further Reading

Design Principles

  1. Economics to design behavior. Explicit economic mechanism design can achieve implicit economic incentives found in other social contracts (i.e. consensus protocols like proof of work). If you like analogies, search “big games” in History of Casper part 3.
  2. Maximize cost of attack. For example, the amount of damage that an attacker can do to a protocol’s utility should be bound by some “griefing factor.” In order to do $100 of damage, it shouldn’t cost $0.01. It should hopefully cost in the order of $100. In other words, we want to minimize the “attack multiple” of each dollar used for attacking the protocol (more on this coming in another post).
  3. Public cost-benefit, not just private. Protocol economics should account for social (i.e. “public”) cost & benefit (negative and positive externalities) as we begin scaling public blockchains. Energy cost, environmental impact and wealth distribution are some notable examples.
  4. Prevent economies of scale. Centralization weakens the main value proposition of public blockchains. Preventing economies of scale prevents those centralizing factors and build more secure blockchains.
  5. Network security is derived from “skin in the game.” Simple yet worth reiterating. The more you have to lose, the more we can trust you as a validator. Whereas burning energy secures proof of work chains, “putting up economic value-at-loss” secures proof of stake chains.
  6. Design for oligopolies. Cooperative game theory is the name of the game as a protocol won’t be able to fully mitigate the inherent centralizing forces (e.g. economies of scale) in a network. This means analyzing all edge cases that involve self-interested cartel behavior. Notably, a protocol should disincentivize cartels from bullying non-cartel validators (i.e. be “friendly”)
  7. Accountable safety. Design that makes it possible to attribute faults to bad actors as much as possible. Casper relies on the ability to slash attributable Byzantine behavior.
  8. Plausible liveness. Design that doesn’t allow attackers to block the chain from continuing to propose and vote on checkpoints/blocks. This is where Casper differs from other implementations such as Tendermint, which will “lock up” if safety isn’t achieved synchronously.
  9. Minimal synchronicity assumptions. To allow for liveness and “unblock” the chain growing, Casper has minimal synchronicity assumptions. In fact, we expect nodes to log on as infrequently as every couple of months.
  10. Decentralized things should be able to regenerate. A protocol is decentralized only if it can fully recover from the permanent removal of all but one of its nodes. Availability, not just consistency (Again, Tendermint is susceptible to getting “blocked” and cannot regenerate; the validator set for each branch can keep getting smaller per Matthew Wampler-Doty and Vlad’s observation)
  11. Disincentivize censorship. The major tradeoff is that validators have a new attack vector by deliberately going offline. However, cartel censorship is the greater evil here. Choosing the right relative cost of censorship vs. rewards and other penalties (as a % of deposits) will be the key to getting this right.

Further Reading


Challenges for Proof of Stake

Long range attack — Same mechanism as 51% attack (make a longer chain that rewrites the ledger in the attacker’s favor), but instead of starting the attack 6 blocks back, go much further back in the chain’s history (i.e. 60,000 blocks). This is a problem for PoS since there’s no proof of work (or equivalent time-intensive operation) required to rewrite a very long chain.

These two main challenges are solved via ideas from slasher (and its improved variations). The main points are that (1) validators are known, which allow for fault attribution at a validator level and (2) by having “slashing conditions” that strongly disincentivize certain actions, it is possible to mitigate these issues. Again, this example is crucial in understanding the Casper team’s view on consensus algorithm design: we can leverage economic mechanism design to a secure distributed system.

Criticisms of Proof of Stake

This falls under future work and an area of great focus for the research team: cryptoeconomics. As the parametrization of the mechanism is progresses, the team will iterate on optimizing the constants the balance the risk reward tradeoffs as well as their proportion to the size of the deposits and the action of others (Byzantine behavior).

It’s worth mentioning that this problem is also existent (albeit to a lesser degree given the nature of proof of work) in Bitcoin.

“The rich get richer” — Another common concern when people hear “a consensus algorithm based on how much money you’re staking” is that this may exacerbate wealth inequality within the crypto ecosystem as well as more broadly in the global economy.

The main takeaway here should be that Proof of Stake is considerably more egalitarian (i.e. gives less benefit to having more capital) than the incumbent Proof of Work based algorithm of Bitcoin.

As discussed in the Proof of Stake overview above, PoS mitigates economies of scale, which diminishes the centralizing force among miners. Again, in PoS, a dollar is a dollar.

Therefore, against the fair intuition that PoS can exacerbate wealth inequality, it is in fact a non-trivial improvement on the status quo.

Quick aside: In order to have diseconomies of scale or progressive wealth distributions in PoS (one more degree of counteracting wealth inequality), I posit that it is necessary to have mature and reliable identity or reputation systems. Otherwise, larger pools of money will have “sybil behavior” that spreads their wealth over many “less wealthy” false identities that will collectively capture the benefits of a progressive reward system. However, this challenge is out of scope for Casper and will be faced further down the road.

Questions/Concerns around Casper

“How does Casper differ from Tendermint?”
The simplified answer here is that Casper focuses on liveness (availability) and can accept less immediate safety (correctness). While Tendermint is a great project, its downside is that the chain will stall if a checkpoint doesn’t have 2/3 of the votes. That is one of the reasons why Ethereum is working on Casper rather than working off of Tendermint.

To quote Vlad Zamfir:

Tendermint favours consistency over availability, Casper favours availability over consistency (see the CAP theorem).

Tendermint doesn’t punish online validators for potentially censoring potentially-actually-just-offline validators.

For further reading on this topic: Hudson Jameson’s explanation this quote, reddit discussion featuring Vitalik & Jae Kwon, and the Tendermint whitepaper.

😱 You’re going to change the engine of a live $28B network?”
Yes, that is very ambitious and daunting. However, moving to PoS was the intent since the early days, and one of the guiding principles of the project. The community members were very much aware of Ethereum’s plans to switch to PoS (i.e. refer to Ethereum Ice Age — the PoW chain difficult adjustment to encourage migration to PoS — which is commonly known in the ecosystem).

This should go without saying, but the team will be rolling out the change in stages with the test network. Also, the initial implementation is a hybrid where the PoS elements have less of an economic impact — and therefore impact on security — than in the eventual “pure” PoS consensus.

“In practice, transactions are cleared in 10 blocks. Why does finality matter over a 50 block epoch?”
We covered this above, but let’s go over this once again since it’s important.

First, Casper enables sharding.

This was very unclear to me in the beginning, but that’s because we need to take a step back from Casper for a moment. Ethereum has many goals, but one of them is to provide a scalable blockchain solution, both technically and environmentally. Ethereum is building for a world where cryptocurrencies have a larger place in the global economy and grow by many orders of magnitude. In that vision, Casper aims to prevent the wasted energy of PoW mining but we still need to scale Ethereum technically. That project is largely encompassed under sharding.

Today, every node in the network does everything. Sharding explores various ways to decrease the average responsibility of each node. The details are out of scope of this post, but an example might be to pose the question: “are there ways to create a new mechanism, where only small subset of nodes verifies each transaction?”

The takeaway is that the periodic finality provided by Casper will mitigate lower security related to implementing sharding.

Second, explicit finality allows for a consistency-favoring blockchain. To quote Vitalik:

In a PoW chain, if there is, for example, a geth/parity consensus split, then both chains keep growing, and exchanges running one client or the other risk finalizing deposits on a bad chain. But if exchanges wait for Casper finality, then in a 50/50 split it’s likely *neither* chain will finalize. This increases the safety of the platform, as in extreme circumstances it “defaults toward finalizing nothing” rather than finalizing *the wrong thing*.

In sum, contrary to intuition, explicit finality matters less for transaction clearing and more for blockchain scalability and safety.

Future Work


  • Implementing proof of concept code.
  • Deploying into test nets.

“The One Casper”

Parameter Optimization

Community Education

Potential Future Posts

  • Deep dive into how Casper enables sharding
  • Deep dive into how and why Casper is different from competing designs
  • Non-monetary measures of “stake” and “skin in the game” (i.e. $10,000 is worth more to average person than billionaire)
  • Griefing Factor Analysis 2.0


Proof of Stake — a category of consensus algorithms for public blockchains that depend on a validator’s economic stake in the network.

Casper — Ethereum’s proof of stake research and projects.

Finality — Once an operation in a system completes, the system doesn’t allow for the operation to be reverted (Vitalik on settlement finality). Context: in proof of work, finality is probabilistic and implicit. Casper is designing mechanisms that explicitly enforce finality.

Fork Choice Rule — A fork choice rule is a function, evaluated by the client, that takes as input the set of blocks and other messages that have been produced, and outputs to the client what the “canonical chain” is.

Slashing Conditions — Set of rules that, if violated, penalize the validator.

Sybil Attack — an attack wherein a reputation system is subverted by forging identities in peer-to-peer networks.

3 E’s of Sybil Resistance — 1. Entry Cost 2. Existence Cost 3. Exit Penalty. (coined by Dominic Williams).

Nothing-at-stake problem — A proof of stake implementation challenge that refers to the inherent lack of downside for validating both chains in the case of a fork. It is a well-known problem of proof of stake that is considered solvable. For example, refer to Slasher.

Bribe attack — Attacker uses a bribe to change the Nash Equilibrium of a validator’s game theory framework to undermine the security of the protocol. (More context in History of Capser pt 2)

Long range attack — Same mechanism as 51% attack (make a longer chain that “rewrote” the ledger in the attacker’s favor), but instead of starting the attack 6 blocks back, go much further back in the chain’s history (think 60,000 blocks).

DAG — “Directed Acyclic Graph”. A finite directed graph with no directed cycles. (ETH Stack Exchange).

GHOST — “Greedy Heaviest Observed Subtree.” It’s a chain selection rule with the objective of fast confirmation times while limiting compromises in security or decentralization. (Original Paper, ETH GHOST)

Synchronicity — Refers to the timing assumptions around the messages (i.e. synchronous, partially synchronous and asynchronous).

Liveness — “Availability.” Protocol-following nodes eventually decide on a value. Opposite would be a network state that is blocked from deciding on a value (i.e. Tendermint without 2/3 votes at a given depth)

Safety — “Correctness.” Protocol-following nodes decide on the same value. Another intuitive proxy is whether two conflicting blocks can be committed.

FLP Impossibility Theorem — “It’s impossible to have a live, safe and asynchronous network” (formally proven as well).

Accountable Faults — Faults that can be attributed to a specific validator or specific set of validators.

Byzantine Faults / Byzantine Behavior — Any fault presenting different symptoms to different observers. Non-protocol following behavior.

Byzantine Failure — Loss of a system service due to Byzantine faults in a system that requires consensus.

Byzantine Fault Tolerance (“BFT”) — Ability for a system to tolerate Byzantine faults. 1/3 Byzantine fault threshold in asynchronous networks. 1/2 in synchronous networks. (BFT consensus algorithms include Paxos, PBFT as well as newer Casper and Tendermint).

Nakamoto Consensus — PoW-based bitcoin-style consensus building. Also, Nakamoto-style Consensus exists, which would be chain-based PoS as opposed to BFT-based PoS.

Tendermint — Proof of Stake implementation that focuses on consistency. Never forks with less than 1/3 malicious actors, but downside is that the chain can stall if a chain lacks 2/3 of the validator votes.

Validator — An entity that validates checkpoints/blocks of a blockchain for rewards. A miner analog in PoS.

Validator Set — Set of validators for a given chain at any given time.

Checkpoint — In FFG, it is a block spaced in regular intervals (i.e. every 50 blocks) where the PoS validation mechanism is overlaid on top of the underlying PoW chain (e.g. Ethereum with ethash)

Epoch — In FFG, it is a 50 block period where a validator can vote on the finality of its final block (i.e. checkpoint). PoW miners mine blocks and PoS validators validate checkpoints every epoch.

Dynamic Validator Sets — The idea that a blockchain can have changing set of validators throughout a period. Treatment of this is a huge breakthrough in BFT-style consensus algorithms. Tendermint was first notable breakthrough. Casper is also working on this actively.

Equivocation — The act of a validator sending two messages that conflict with each other (more specific definition on slide 28 of this deck).

Dunkles — Mechanism that includes data from non-dominant block into the dominant block. This provides better incentive mechanisms and notably helps alleviate the nothing-at-stake problem (link).

Proposal Mechanism — Mechanism by which a validator in the set will suggest a block to assess for justification or finalization.

Justification —In FFG for example, 2/3 of a validator set voting on a fresh checkpoint that a checkpoint is the accurate record. This is the intermediary step for a finalized checkpoint.

Finalization — In FFG for example, 2/3 of a validator set voting on a justified checkpoint that a checkpoint is the accurate record. The completion of this step gives a checkpoint finality.

State Transition System — A system that maintains a given state (e.g. set of transactions or accounts) and its mutations over time (i.e. transition). Bitcoin, Ethereum, and other public blockchains can be considered state transition systems.

Protocol Utility Function — “…a formula that tells us how well the protocol is doing, that should ideally be calculable from inside the blockchain. In the case of a proof of work chain, this could be the percentage of all blocks produced that are in the main chain. In Casper, protocol utility is zero for a perfect execution where every epoch is finalized and no safety failures ever take place, with some penalty for every epoch that is not finalized, and a very large penalty for every safety failure. If a protocol utility function can be formalized, then penalties for faults can be set as close to the loss of protocol utility resulting from those faults as possible.” (from Triangle of Harm)


If you want to dive deeper, dive into the resources linked throughout the post, consider contributing to the future work, and talk to your math, CS, economics, game theory, and distributed systems friends (in and out of crypto) about Ethereum and Casper.

If you’ve made it this far, thank you for reading. Hope this helped and please reach out with questions, concerns or comments via email or twitter. We would love to hear your feedback!

Special thanks to Vitalik Buterin, Vlad Zamfir, Virgil Griffith and Karl Floersch for discussion and review. All errors remain my own.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store