Ethermint has existed in one form or another for quite awhile. The most recent version (v2) has been shepherded by ChainSafe via a grant from the ICF. At it's core it is the Ethereum Virtual Machine built as a Cosmos SDK module. It comes with a REST client that exposes an Ethereum RPC endpoint (defualt localhost:8545) that accepts all normal etheruem interactions. This includes pointing common Etheruem tools like Truffle or Metamask to the endpoint and interacting with it like a normal Ethereum network. The benefit of running Ethermint instead of GoEthereum (GETH) or the Parity Client is that instead of just a Proof-Of-Authority validation (or classic proof of work) Ethermint uses Tendermint consensus. Furthermore, by being present within the Cosmos SDK, it is possible for the other modules to interact directly with Ethermint. For example, hooks can be set in `BeginBlock` or `EndBlock` which will be executed on the EVM at the beginning or ending of each block. This would allow things like subscriptions to be executed automatically. It would also allow things like contract deployment to be routed via governance so that not just anyone can deploy code but only those approved by Governance.

Peggy has also existed in one form or another for quite some time. In general, Peggy is an oracle layer that allows communication between networks with probabilistic finality like Ethereum. An early version was created by @joon#0284 as part of a hackathon. More recent versions of unidirectional peggy and bidirectional peggy have been created by SwishLabs. Peggy currently supports the transfer of Ether and ERC-20s from an EVM based chain that it is connected to. Currently it works like this:

Validators run on the SDK chain like normal. These validators have voting power based on token balances, referred to as weight. This weight gives them authority to validate blocks, but it also give them authority to make claims about the state of Ethereum. If a user locks up Ether or an ERC-20 on Ethereum (or any other EVM based chain that Peggy is made aware of), one or more validators are able to witness this event and make a claim about the event on the SDK chain. Once there is a threshold of validators who have made the same claim with enough weight, the claim is considered valid. A valid claim will result in a corresponding token being minted in the SDK owned by an address designated in the original lock-up transaction. If the claims never reach a threshold, it is considered a failed claim and marked as so.

This is the basics of the original unidirectional bridge but peggy also has the feature of moving assets from the SDK chain to the EVM based chain. In this scenario there are either tokens on the SDK chain which originated there, or tokens which were minted there based on validator claims of the tokens being locked up on the EVM chain. I will refer to these as SDK-Native-SDK-Tokens and EVM-Native-SDK-Tokens respectively.

When an SDK-Native-SDK-Token is moved to the EVM chain, it is moved to an escrow account on the SDK chain and an event is emitted. The validators will witness this event and make a claim on the EVM chain about such an event. The EVM chain keeps a record of all the SDK validators and their corresponding weights. Similarly to the EVM -> SDK process, a threshold of weight is required before the Claim is considered valid. At that point the EVM contract will mint a new token that represents the SDK-Native-SDK-Token. This new token will be a SDK-Native-EVM-Token.

When an EVM-Native-SDK-Token is moved to the EVM network, it will be burned. That is because the token originated on the EVM chain and has a corresponding token locked up on the EVM chain. Since it is moving back to its orignial setting, the token that representation on the SDK chain is no longer needed and can be safely burned. An event is emitted and the validators will similarly relay the message to the EVM network as a claim. Once a threshold of claims have been made the corresponding EVM-Token will be unlocked on behalf of the sender.

When SDK-Native-EVM-Tokens need to be sent back to the SDK Network, they are similarly burned on the EVM side as part of the claim and transfer process.

Points where Peggy could still benefit from development are when and how the validator set is updated on the EVM chain. Currently there is a trusted operator who is able to add, edit and remove validators from the EVM network. A malicious operator could replace all validators with accounts they control and steal all funds. It is important that any use of the current implementation of Peggy have an operator that can be trusted.

Future improvemens of peggy would be finding a solution for replacing the operator account. Peggy itself could be used to make updates to the validator set and weights, or an external oracle could be used to keep the EVM contract updated with correct validator sets and validator weights.