{"id":13566120,"url":"https://github.com/CosmWasm/mesh-security-hackathon","last_synced_at":"2025-04-03T23:31:08.440Z","repository":{"id":60599841,"uuid":"544155381","full_name":"CosmWasm/mesh-security-hackathon","owner":"CosmWasm","description":"Implementation of Sunny's Mesh Security talk (Hackathon / Prototype status)","archived":false,"fork":false,"pushed_at":"2023-04-24T14:49:02.000Z","size":1545,"stargazers_count":88,"open_issues_count":13,"forks_count":19,"subscribers_count":9,"default_branch":"main","last_synced_at":"2025-03-25T13:11:30.471Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/CosmWasm.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":"docs/ROADMAP.md","authors":null}},"created_at":"2022-10-01T19:42:35.000Z","updated_at":"2024-10-01T11:23:39.000Z","dependencies_parsed_at":"2024-01-19T07:08:19.138Z","dependency_job_id":"0f9129ec-5655-491b-b53f-e7ebe1cf5688","html_url":"https://github.com/CosmWasm/mesh-security-hackathon","commit_stats":null,"previous_names":["cosmwasm/mesh-security-hackathon"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CosmWasm%2Fmesh-security-hackathon","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CosmWasm%2Fmesh-security-hackathon/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CosmWasm%2Fmesh-security-hackathon/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CosmWasm%2Fmesh-security-hackathon/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/CosmWasm","download_url":"https://codeload.github.com/CosmWasm/mesh-security-hackathon/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247097671,"owners_count":20883122,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-01T13:02:02.517Z","updated_at":"2025-04-03T23:31:06.195Z","avatar_url":"https://github.com/CosmWasm.png","language":"Rust","funding_links":[],"categories":["Rust"],"sub_categories":[],"readme":"# mesh-security (Hackathon / Prototype status)\n\n**Note** this is working (but fragile) code from Sep 2022 Medellin HackWasm. Feel free to bang on it to\nunderstand Mesh Security better. As of April 2023, we have started a new repo \n[osmosis-labs/mesh-security](https://github.com/osmosis-labs/mesh-security), which will host\nwork towards a full production-quality implementation of Mesh Security, written by the same\ndevelopers and many more.\n\n## What it is\n\nAn implementation of Sunny's [Mesh Security](https://youtu.be/Z2ZBKo9-iRs?t=4937) talk from Cosmoverse 2022.\n\nThis should run on any CosmWasm enabled chain. This is MVP design and gives people\nhands on use, that should work on a testnet. Open questions that need\nto be resolved before we can use this in production are listed below.\n\n## Architecture\n\nPlease check out the [architectural documentation](./docs/README.md), which gives a thorough view\nof all the components in a completed system.\n\nYou can also look at [Sunny's original flipboard](https://docs.google.com/presentation/d/13JrSdzodhAGRj59-P5e9sxyoDPvVm7ZVvw1GzR8OilQ/edit#slide=id.g15d37737ae2_0_885)\nto get view of the various flows involved.\n\n## Contracts\n\n* `meta-staking` - a bridge between the rest of the contracts and the x/staking module to\n  provide a consistent, friendly interface for our use case\n* `mesh-lockup` - a contract that locks tokens and allows lockers to issue multiple claims\n  to other consumers, who can all slash that stake and eventually release their claim\n* `mesh-provider` - an IBC-enabled contract that issues claims on an ILP and speaks IBC to a consumer. It\n  is responsible for submitting slashes it receives from the `slasher` to the `ilp` contract.\n* `mesh-consumer` - an IBC-enabled contract that receives messages from `ibc-provider` and\n  communicates with `meta-staking` to update the local delegations / validator power\n* `mesh-slasher` - a contract that is authorized by the `mesh-provider` to submit slashes to it. There can\n  be many types of slasher contracts (for different types of evidenses of misbehaviors)\n\n## Overview for Users\n\n**High Level:** You connect Osmosis to Juno and Juno to Osmosis. We will only look at one side\nof this, but each chain is able to be both a consumer and producer at the same time.\nYou can also connect each chain as a provider to N chains and a consumer from N chains.\n\nLet's analyze the Osmosis side of this. Osmosis is the provider of security to Juno.\nOnce the contracts have been deployed, a user can interact with this as follows.\n\n#### Cross-staking:\n\n1. User stakes their tokens in the `mesh-lockup` contract on Osmosis\n2. User can cross-stake those tokens to a Juno `mesh-provider` contract (on Osmosis), specifying how many of their \n   tokens to cross-stake and to which validator\n3. The Osmosis `mesh-consumer` contract (on Juno) receives a message from the counterparty `mesh-provider` contract\n   and updates the stake in the `meta-staking` contract (on Juno).\n4. The `meta-staking` contract checks the values and updates it's delegations to `x/staking` accordingly. (The\n   meta-staking contract is assumed to have enough JUNO tokens to do the delegations. How it gets that JUNO is\n   out of scope.)\n\n#### Claiming Rewards:\n\n1. Anyone can trigger the Osmosis consumer contract to claim rewards from the `meta-staking` contract\n2. The `mesh-consumer` contract (on JUNO) sends tokens to the `mesh-provider` contract (on Osmosis) via ics20\n3. The `mesh-consumer` contract sends a message to the `mesh-provider` contract to inform\n   of the new distribution (and how many go to which validator).\n4. The `mesh-provider` (on Osmosis) contract updates distribution info to all stakers, allowing them to claim\n   their share of the $JUNO rewards on Osmosis.\n\n#### Unstaking:\n\n1. A user submits a request to unstake their tokens from the `mesh-provider` contract (on Osmosis)\n2. We update the local distribution info to reflect the new amount of tokens staked\n3. This sends a message to the `mesh-consumer` contract (on Juno), which updates the Juno `meta-staking` contract\n   to remove the delegation.\n4. The `mesh-provider` contract (on Osmosis) gets the unbonding period for this cross stake by querying\n   the `slasher` contract\n5. After the unbonding period has passed (eg. 2 weeks, 4 weeks) the `mesh-provider` contract\n   informs the `mesh-lockup` contract that it removes its claim.\n6. If the user's stake in the `mesh-lockup` contract has not more claims on it, they can withdraw their stake.\n\n#### Slashing:\n\n1. Someone calls a method to submit evidence of Juno misbehavior on the `meta-slasher` contract (on Osmosis).\n2. The `meta-slasher` contract verifies that a slashing event has indeed occurred and makes a contract call to the\n   `mesh-provider` contract with the amount to slash.\n3. The `mesh-provider` updates the `mesh-lockup` stakes of everyone delegating to the offending validator. Tokens are unbonded\n   and scheduled to be burned.\n4. `mesh-provider` sends IBC packet updates to the `mesh-consumer`s on all other chains about the new voting power.\n\n#### Claiming tokens:\n\nA user can stake any number of tokens to the `mesh-lockup` contract, and use them in multiple provider contracts.\nThe `mesh-lockup` contract ensures that the user has balance \u003e= the max claim at all times.\nIf you put in eg 1000 OSMO, but then provide 700, 500, and 300 to various providers,\nyou can pull out 300 OSMO from the `mesh-lockup` contract. Once you successfully release the claim on the\nprovider with 700, then you can pull out another 200 OSMO.\n\n## Overview for Installing\n\n1. Deploy the contracts to Osmosis and Juno\n2. `x/gov` on Juno will tell the \"Osmosis consumer contract\" which `(connectionId, portId)` to trust\n3. `x/gov` on Juno will provide the \"Osmosis consumer contract\" with some JUNO tokens with which it can later delegate\n   (This is a hacky solution to give the consumer contract OSMO to be able to stake... we discuss improvement below).\n4. A relayer connects the two contracts, the consumer contract ensures that the channel is made\n   from the authorized `(connectionId, portId)` or rejects it in the channel handshake. It also\n   ensures only one channel exists at a time.\n5. Once the trusted connection is established and the consumer contract has been granted sufficient\n   delegation power, then the user flow above can be used.\n\n## Features to add\n\nThese are well-defined but removed from the MVP for simplicity. We can add them later.\n\n* `mesh-lockup` must also allow local staking, and tie into the meta-staking contract to use that\n  same stake to provide security on the home chain.\n\n## Open Questions\n\nThese are unclear and need to be discussed and resolved further.\n\n* How to cleanly grant consumer contracts the proper delegation power?\n  * Something like \"superfluid staking\" module where we can mint \"synthetic staking tokens\"\n    that work like normal, but are removed from the \"totalSupply\" query via offset.\n  * Fork `x/staking` to allow such synthetic delegations that don't need tokens.\n    This is a hard lift, but would allow custom logic, like counting those tokens\n    in tendermint voting power, but exclude them from `x/gov`, and decide on some\n    reducing factor for their rewards.\n* How to cleanly define limits for the providing chains on how much power they can\n  have on the consuming chain? We start with a fixed number (# of JUNO), but better\n  to do something like \"max 10% of total staking power\".\n* Ensure a minimum voting power for the local stake. If we let 3 chains each use up to 30%\n  of the voting power, and they all stake to the max, then we only have 10% of the power locally.\n  We can set a minimum to say 40% local, and if all remote chains stake to the max, their\n  relative powers are reduced proportionally to ensure this local minimum stake.\n* How to normalize the token values? If we stake 2 million $OSMO, we need to convert that\n  to the same $$ value of $JUNO before using it to calculate staking power on the Juno chain.\n* How to properly handle slashing, especially how a slashing on JUNO triggers a slash on OSMO,\n  which should then reduce the voting power of the correlated validators on STARS\n  (that was based on the same OSMO stake). This is a bit tricky, IBC messages could be sent out\n  to all consumer chains, but there could be performance implications for this.\n* Desired reward payout mechanism. For MVP, we treat this as a normal delegator and\n  send the tokens back to the provider chain to be distributed. But maybe we calculate\n  rewards in another way, especially when we modify `x/staking`. Should also be computationally\n  efficient\n* How to improve installation UX? Ideally, when the consumer chain votes to instantiate\n  mesh security with another chain, all contracts are deployed and configured in one governance\n  prop.\n* How to handle changing prices? What is a good price oracle? We need to update the voting\n  power of the consumer contract when the price changes. This may lead to issues in normalization\n  especially if the remote token price rises considerably.\n* What do we do when the consumer stake is greater than the max allowance? Do we fail that extra Stake?\n  Do we normalize the validators within that consumer? Failing is easier, but not possible in\n  response to price oracle changes. For example, if max power is 1000 and we have 500 for val A and 1000\n  for val B and 1000 for val C, we could normalize to A=200, B=400, C=400.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FCosmWasm%2Fmesh-security-hackathon","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FCosmWasm%2Fmesh-security-hackathon","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FCosmWasm%2Fmesh-security-hackathon/lists"}