Core updates (part 2) (#147)

src/pages/core/advanced/measuring-time.mdx

@@ -27,4 +27,9 @@ But you can rely on this timestamp to have the following properties:
 - Consistent across the chain (every validator on the chain has the same info)
 - Monotonic (it will ever only increase or stay the same; never decrease)
 
+Read more about [BFT Time] and [Proposer-Based Timestamps (PBTS)][PBTS] if you want to better understand
+where the time value comes from.
+
 [found here]: https://docs.rs/cosmwasm-std/latest/cosmwasm_std/struct.BlockInfo.html
+[BFT Time]: https://docs.cometbft.com/main/spec/consensus/bft-time
+[PBTS]: https://informal.systems/blog/introducing-proposer-based-timestamps-pbts-in-cometbft

src/pages/core/architecture/events.mdx

@@ -6,8 +6,8 @@ import { Callout } from "nextra/components";
 
 # Events
 
-CosmWasm can emit [Cosmos Events]. These events are stored in the block as metadata, allowing the contract
-to attach metadata to what exactly happened during execution.
+CosmWasm can emit [Cosmos Events]. These events are stored in the block execution result as metadata,
+allowing the contract to attach metadata to what exactly happened during execution.
 
 <Callout>
 
@@ -19,7 +19,7 @@ Some important details about the keys:
 
 </Callout>
 
-By default CosmWasm emits the `wasm` event to which you can add context like so:
+By default CosmWasm emits the `wasm` event to which you can add attributes like so:
 
 ```rust filename="wasm_event.rs" template="core"
 let response: Response<Empty> = Response::new()

src/pages/core/architecture/transactions.mdx

@@ -14,12 +14,17 @@ the contract entrypoint returns an error or panics.
 
 ## Preventing rollbacks in case of failure
 
-If you don't want your entire transaction to be rolled back in case of a failure, you can use the
-`reply_on` field in the message you send. Set the field to one of the following values and instead
-of rolling back the transaction, you will receive a message containing the error:
+If you don't want your entire transaction to be rolled back in case of a failure, you can split the
+logic into multiple messages. This can be two contracts, a contract executing itself or a contract
+that sends a message to a Cosmos SDK module. Then use the `reply_on` field in the message you send.
+Set the field to one of the following values and instead of rolling back the transaction, you will
+receive a message containing the error:
 
 - `ReplyOn::Always`
 - `ReplyOn::Error`
 
 That way you can handle the error and decide what to do next, whether you want to propagate the
 error, retry the operation, ignore it, etc.
+
+The default value `ReplyOn::Success` means the caller is not ready to handle an error in the message
+execution and the entire transaction is reverted on error.

src/pages/core/conventions/library-feature.mdx

@@ -9,21 +9,7 @@ import { Callout } from "nextra/components";
 In the ecosystem, there is the convention to gate the entrypoints of your contract behind a
 compile-time feature. The feature is conventionally called `library`.
 
-So instead of doing this:
-
-```rust filename="contract.rs" template="core"
-#[cfg_attr(not(feature = "library"), entry_point)]
-pub fn instantiate(
-    _deps: DepsMut,
-    _env: Env,
-    _info: MessageInfo,
-    _msg: InstantiateMsg,
-) -> StdResult<Response> {
-    Ok(Response::new())
-}
-```
-
-You should do this:
+So instead of using the `#[entry_point]` macro directly, you should do this:
 
 ```rust filename="contract.rs" template="core"
 #[cfg_attr(not(feature = "library"), entry_point)]