docs-migration-tres

SECURITY.md

@@ -1,6 +1,6 @@
 # Security Policy
 
-At Composable Finance we are always striving towards writing secure and stable code. If you have found a critical bug or a security  
+At Composable, we are always striving towards writing secure and stable code. If you have found a critical bug or a security  
 vulnerability, you can simply report your findings to us.  
 
 
@@ -15,7 +15,7 @@ When you report a security vulnerability please include:
 The more information you provide the better. We recommend submitting a report where you describe the vulnerability, show us how you found it and provide reproducible code samples.
 Providing mitigation advice is also recommended.
 
-**The report should be submitted to reporting@composable.finance.**
+**The report should be submitted to security@composable.finance.**
 
 
 ## Responsible Disclosure   
@@ -29,4 +29,4 @@ What is currently in scope is finding bugs in a our code base running in a local
 
 
 ## Rewards   
-Rewards are granted depending on the severity of the vulnerability, ranging from $50 to $30.000, payed out in PICA tokens. 
+Rewards are granted depending on the severity of the vulnerability, payed out in PICA tokens. 

docs/docs/concepts/picasso.md

@@ -18,7 +18,7 @@ There are plans to modify the consensus of Picasso to Kauri, a Byzantine Fault T
 
 The IBC Protocol is used for trust-minimized communication between different blockchain networks/ecosystems. It relies on security at the consensus level of the two transacting chains, and this is a large reason why IBC was selected as a cornerstone of Picasso's efforts to connect ecosystems, in addition to its performance and standardization. 
 
-Originally, IBC was tailored for native connections between Cosmos SDK chains. Extending this to include more networks required significant development effort. In fact, IBC on Solana, Ethereu, Polkadot and Kusama all require respective customization from implementation of light client to achieving state proof (finality), in order to not rely on any centralized intermediary and uphold the IBC standards and values of censorship resistance.
+Originally, IBC was tailored for native connections between Cosmos SDK chains. Extending this to include more networks required significant development effort. In fact, IBC on Solana, Ethereum, Polkadot and Kusama all require respective customization from implementation of light client to achieving state proof (finality), in order to not rely on any centralized intermediary and uphold the IBC standards and values of censorship resistance.
 
 These connections allow the transfer of both fungible (e.g Tokens) and non-fungible tokens (NFTs), generic message passing, cross-chain contract calls, cross-chain fee payments, and cross-ecosystem collateralization, all executed in a natively secured environment.
 
@@ -30,13 +30,16 @@ Picasso expands upon the concept of restaking popularized by [Eigenlayer](https:
 
 We believe that all assets that have underlying utility, community, and liquidity, given long enough horizon, will have various level of economic value that can be used to enhance security guarantees for many use-cases (interoperability, oracles, sequencers and more) built upon the Proof of Stake consensus mechanism.
 
-## Governance
-Similar to the way that majority of Cosmos SDK chains operate, validators can vote using tokens they are delegated with. However, if a delegator votes themselves, their voting decision will override the validator’s vote if the decision differs. The parameters for the governance on Picasso are as follows:
+## Staking PICA
 
-| Parameter                                          | Period/Number  |
-|----------------------------------------------------|----------------|
-| Total Deposit                           | 2 million PICA          |
-| Quorum          | 30%         |
-| Voting Period | 1 day        |
-| Threshold                | 50% |
-| No-with-veto                             |  33%   |
+A portion of the bridging fees generated by each new IBC connection implemented via Picasso will be allocated to stakers of PICA. Currently, stakers receive rewards from the Polkadot-Cosmos and the Ethereum IBC implementation, with fees from Solana activity to be included upon launch.
+
+To handle fees collected in the form of the bridged token, a mechanism will be implemented to use these fees to buy back PICA from the market and distribute them to stakers as rewards. For instance, if ETH is bridged from Ethereum mainnet to Solana, 20% of the fees collected from this transfer will be used to buy back PICA and distribute it to PICA stakers. This process will be standardized for all tokens transferred across the bridge.
+
+PICA is essential for securing Picasso. To participate in governance activities, PICA must be staked on the network. Governance decisions on Picasso will include determining AVS and Operator onboarding, as well as adding new liquid staked assets to the restaking layer.
+
+The Generalized Restaking Layer will ensure the security of launches and activities of various Actively Validated Services (AVS), boosting revenue generation for PICA stakers. Specifically, 20% of the revenue will be allocated to PICA stakers. The initial AVS to be launched will be the AVS for Solana IBC.
+
+:::tip
+Follow [this guide](https://docs.composable.finance/user-guides/pica-staking) for staking PICA on Picasso to take part in governance and earn rewards through various protocol revenue streams.
+:::