diff --git a/docs/5.api/rpc/transactions.md b/docs/5.api/rpc/transactions.md
index 2821a72e8cc..c37fb0fb826 100644
--- a/docs/5.api/rpc/transactions.md
+++ b/docs/5.api/rpc/transactions.md
@@ -470,6 +470,36 @@ http post https://rpc.testnet.near.org jsonrpc=2.0 id=dontcare method=tx \
 </p>
 </details>
 
+<blockquote class="warning">
+<strong>heads up</strong><br /><br />
+
+In the case of function call transactions, this query will not wait for **all** receipts generated by this transaction to finish before returning a result. Rather, it will only wait for its return value to finish before returning; _which could be a promise_.
+
+Let's say a transaction only contains a "function call" action that calls a `transfer()` method like the one below _(written in [Rust](https://www.rust-lang.org/))_. It will only wait for the "function call" receipt, not necessarily the receipt from the actual transfer of funds to finish before returning a result.
+
+```rust
+pub fn transfer(receiver_id: String) {
+    Promise::new(receiver_id).transfer(10);
+}
+```
+
+However, if we slightly modify the function to have the promise as a return value, then the `tx` status query will wait for this promise to finish _before_ returning results.
+
+```rust
+pub fn transfer_promise(receiver_id: String) -> Promise {
+    Promise::new(receiver_id).transfer(10)
+}
+```
+
+Despite such design, the `tx` endpoint can be used to check whether all receipts have finished.
+
+Instead of looking at the main result `status`, we can check all of the receipts
+returned `status` and see if any are `Unknown`. If none of the receipts statuses are unknown, we can be certain that all receipts generated have finished.
+
+In addition, `tx` endpoint does not provide finality guarantees. To make sure that the entire execution is final, it suffices to ensure every `block_hash` in every outcome is `final`.
+
+</blockquote>
+
 #### What could go wrong? {#what-could-go-wrong-2}
 
 When API request fails, RPC server returns a structured error response with a limited number of well-defined error variants, so client code can exhaustively handle all the possible error cases. Our JSON-RPC errors follow [verror](https://github.com/joyent/node-verror) convention for structuring the error response: