diff --git a/docs/sidebars.js b/docs/sidebars.js
index 4ebe47978c..2942cb3b01 100644
--- a/docs/sidebars.js
+++ b/docs/sidebars.js
@@ -171,6 +171,7 @@ module.exports = {
       "proposals/rust-clients",
       "proposals/optimistic_confirmation",
       "proposals/embedding-move",
+      "proposals/rip-curl",
     ],
   },
 };
diff --git a/docs/src/proposals/rip-curl.md b/docs/src/proposals/rip-curl.md
new file mode 100644
index 0000000000..9905873ca0
--- /dev/null
+++ b/docs/src/proposals/rip-curl.md
@@ -0,0 +1,56 @@
+# RiP Curl: low-latency, transaction-oriented RPC
+
+## Problem
+
+Solana's initial RPC implementation was created for the purpose of allowing
+users to confirm transactions that had just recently been sent to the cluster.
+It was designed with memory usage in mind such that any validator should be
+able to support the API without concern of DoS attacks.
+
+Later down the line, it became desirable to use that same API to support the
+Solana explorer. The original design only supported minutes of history, so we
+changed it to instead store transaction statuses in a local RocksDB instance
+and offer days of history. We then extended that to 6 months via BigTable.
+
+With each modification, the API became more suitable for applications serving
+static content and less appealing for transaction processing. The clients poll
+for transaction status instead of being notified, giving the false impression
+of higher confirmation times. Furthermore, what clients can poll for is
+limited, preventing them from making reasonable real-time decisions, such as
+recognizing a transaction is confirmed as soon as particular, trusted
+validators vote on it.
+
+## Proposed Solution
+
+A web-friendly, transaction-oriented, streaming API built around the
+validator's ReplayStage.
+
+Improved client experience:
+
+* Support connections directly from WebAssembly apps.
+* Clients can be notified of confirmation progress in real-time, including votes
+  and voter stake weight.
+* Clients can be notified when the heaviest fork changes, if it affects the
+  transactions confirmation count.
+
+Easier for validators to support:
+
+* Each validator supports some number of concurrent connections and otherwise
+  has no significant resource constraints.
+* Transaction status is never stored in memory and cannot be polled for.
+* Signatures are only stored in memory until the desired commitment level or
+  until the blockhash expires, which ever is later.
+
+How it works:
+
+1. The client connects to a validator using a reliable communication channel,
+   such as a web socket.
+2. The validator registers the signature with ReplayStage.
+3. The validator sends the transaction into the Gulf Stream and retries all
+   known forks until the blockhash expires (not until the transaction is
+   accepted on only the heaviest fork). If the blockhash expires, the
+   signature is unregistered, the client is notified, and connection is closed.
+4. As ReplayStage detects events affecting the transaction's status, it
+   notifies the client in real-time.
+5. After confirmation that the transaction is rooted (`CommitmentLevel::Max`),
+   the signature is unregistered and the server closes the upstream channel.