Fixing pages related to group admins (#543)

Co-authored-by: Denis Fadeev <[email protected]>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>

src/pages/developers/architecture/privileged.mdx

@@ -19,14 +19,14 @@ policy account has an admin, an address and a decision policy (threshold of
 votes, voting period, etc.).
 
 The group mechanism on ZetaChain is powered by the [`group` Cosmos SDK
-module](https://docs.cosmos.network/v0.46/modules/group/).
+module](https://docs.cosmos.network/v0.50/modules/group/).
 
 ZetaChain can have any number of groups. Anyone can create a group. In this
 document we only consider policy accounts that give authorization to perform
 privileged actions.
 
-These "special" policy accounts are defined in the [params of of the observer
-module](https://zetachain-athens.blockpi.network/lcd/v1/public/zeta-chain/observer/params).
+These "special" policy accounts are defined in the [params of the observer
+module](https://zetachain-athens.blockpi.network/lcd/v1/public/zeta-chain/authority/policies).
 These policy accounts are set during genesis and as any module parameter they
 can be changed through governance. This is important, because even though the
 protocol has a notion of admins and privileged policy accounts, they are chosen
@@ -35,16 +35,15 @@ members of a group become malicious, the community can create a new group with
 new admin and members and use the parameter change governance proposal to point
 the parameter of the observer module to the new policy accounts.
 
-To learn which policy accounts can send which privileged messages, check the
-module documentation and look for "Authorized" notice next to each message.
+To learn which policy accounts can send which privileged messages, query the [zeta-chain/authority/authorizations](https://zetachain-athens.blockpi.network/lcd/v1/public/zeta-chain/authority/authorizations) endpoint. 
 
 <Alert variant="note">
   {" "}
-  Notice that policy accounts below are called "Group1" and "Group2". These are just names that indicate the level of permissions
-  and are not related to the actual groups associated with policy accounts. As you can see in testnet there are two entries
-  ("Group1" and "Group2") and both point to the same policy account. This means that right now even though there are two
-  levels of permissions ("Group1" and "Group2") there is only one policy account that is authorized to perform privileged
-  actions. On mainnet this might change.{" "}
+  Notice that policy accounts below are called "groupEmergency", "groupOperational", "groupAdmin". These are just names that indicate the level of 
+  permissions and are not related to the actual groups associated with policy accounts. As you can see in testnet there are three entries
+  that both point to the same policy account. This means that right now even though there are three
+  levels of permissions ("groupEmergency", "groupOperational", "groupAdmin") there is only one policy account that is authorized to perform   
+  privileged actions. {" "}
 </Alert>
 
 <AdminPolicy />