address PR comments

docs/build/basics/events.md

@@ -79,9 +79,9 @@ event Withdrawn(type: String,
                 balanceAfter: UFix64)
 ```
 
-Mainnet event: `A.0xf233dcee88fe0abe.FungibleToken.Withdrawn`
+Mainnet event: `A.f233dcee88fe0abe.FungibleToken.Withdrawn`
 
-Testnet event: `A.0x9a0766d93b6608b7.FungibleToken.Withdrawn`
+Testnet event: `A.9a0766d93b6608b7.FungibleToken.Withdrawn`
 
 **Deposit Tokens**
 
@@ -96,9 +96,9 @@ event Deposited(type: String,
 
 Event name: `FungibleToken.Deposited`
 
-Mainnet event: `A.0xf233dcee88fe0abe.FungibleToken.Deposited`
+Mainnet event: `A.f233dcee88fe0abe.FungibleToken.Deposited`
 
-Testnet event: `A.0x9a0766d93b6608b7.FungibleToken.Deposited`
+Testnet event: `A.9a0766d93b6608b7.FungibleToken.Deposited`
 
 ### **Fee Events**
 
@@ -117,20 +117,20 @@ An example of fee events:
 ```yml
 Events:
   - Index: 0
-    Type:  A.0xf233dcee88fe0abe.FungibleToken.Withdrawn
+    Type:  A.f233dcee88fe0abe.FungibleToken.Withdrawn
     Tx ID: 1ec90051e3bc74fc36cbd16fc83df08e463dda8f92e8e2193e061f9d41b2ad92
     Values:
-      - type (String): "0x1654653399040a61.FlowToken.Vault"
+      - type (String): "1654653399040a61.FlowToken.Vault"
       - amount (UFix64): 0.00000100
-      - from (Address?): 0xb30eb2755dca4572
+      - from (Address?): b30eb2755dca4572
 
   - Index: 1
-    Type:  A.0xf233dcee88fe0abe.FungibleToken.Deposited
+    Type:  A.f233dcee88fe0abe.FungibleToken.Deposited
     Tx ID: 1ec90051e3bc74fc36cbd16fc83df08e463dda8f92e8e2193e061f9d41b2ad92
     Values:
-      - type (String): "0x1654653399040a61.FlowToken.Vault"
+      - type (String): "1654653399040a61.FlowToken.Vault"
       - amount (UFix64): 0.00000100
-      - to (Address?): 0xf919ee77447b7497
+      - to (Address?): f919ee77447b7497
 
   - Index: 2
     Type:  A.f919ee77447b7497.FlowFees.FeesDeducted

docs/build/basics/transactions.md

@@ -78,7 +78,15 @@ transaction {
 }
 ```
 
-Each account defined as an authorizer must sign the transaction with its own key, and by doing so it acknowledges the transaction it signed will have access to that account and may modify it. How it will modify it is understood from the list of account entitlements that are granted in the `prepare` argument list and by reading the transaction script.
+Each account defined as an authorizer must sign the transaction with its own key,
+and by doing so it acknowledges the transaction it signed
+will have access to that account and may modify it.
+How it will modify it is understood from the list of account entitlements
+that are granted in the `prepare` argument list and by reading the transaction script.
+In an transaction, developers should only give the minimum set of account entitlements
+that are required for the transaction to execute properly.
+This ensures that users who are signing transactions can understand
+what parts of their account a transaction can access.
 
 **Payer**
 

docs/build/smart-contracts/best-practices/security-best-practices.md

@@ -38,7 +38,7 @@ It is preferable to use capabilities over direct `&Account` references when expo
 
 ## Capabilities
 
-Don’t store anything under the [public capability storage](https://cadence-lang.org/docs/language/capabilities) unless strictly required. Anyone can access your public capability using `AuthAccount.capabilities.get`. If something needs to be stored under `/public/`, make sure only read functionality is provided by restricting privileged functions with entitlements.
+Don’t store anything under the [public capability storage](https://cadence-lang.org/docs/language/capabilities) unless strictly required. Anyone can access your public capability using `Account.capabilities.get`. If something needs to be stored under `/public/`, make sure only read functionality is provided by restricting privileged functions with entitlements.
 
 When publishing a capability, the capability might already be present at the given `PublicPath`.
 In that case, Cadence will panic with a runtime error to not override the already published capability.