diff --git a/docs/explicit-accuracy-for-math-round.md b/docs/explicit-accuracy-for-math-round.md
new file mode 100644
index 0000000..cd703f6
--- /dev/null
+++ b/docs/explicit-accuracy-for-math-round.md
@@ -0,0 +1,50 @@
+# Explicit accuracy for math.round
+
+## Summary
+This RFC proposes introducing a second parameter to `math.round` to allow users to declare a degree of accuracy to round numbers to.
+```luau
+print( math.round(3.1415, 2) ) -- Output: 3.14
+```
+
+## Motivation
+The motivation for this proposal lies solely in improving user convenience. Albeit very simple, the concept's current implementation (demonstrated in **Design**) has two major flaws:
+1. It's a 'one-more-than-necessary' utility users have to carry around
+2. Though the difference is negligible in most scenarios, it's computationally slower, even in `native`
+
+Allowing users to specify to what degree of accuracy `math.round` should round to feels like a very simple and appropriate expansion of the standard library. The change is also inherently a performance microoptimization [thanks to the fastcall op].
+
+## Design
+As of writing this, a well-rounded implementation of rounding to a decimal place is something like so:
+```lua
+local function round_to( n: number, decimal_places: number? )
+    assert(type(n) == 'number', 'first arg must be a number')
+    assert((decimal_places == nil) or (type(decimal_places) == 'number'), 'second arg must be a number')
+    decimal_places = math.max(decimal_places or 0, 0)
+    local scale = 10 ^ decimal_places
+    return math.round( n * scale )/scale
+end
+print( round_to(3.1415, 2) ) -- Output: 3.14
+```
+The proposed change provides the same level of convenience as the above `round_to` function without impacting the--for lack of a better term--'visual' size of projects. The change is simple: introduce a second parameter to `math.round` which accepts `number?`s.
+```lua
+-- proposed change
+print( math.round(3.1415, 2) ) -- Output: 3.14
+```
+`math.round`'s new type signature would be `( n: number, decimal_places: number? ) -> number`.
+
+This RFC won't make any suggestions for handling edge cases (ie. if the `decimal_places` input is a negative number, or a non-nil but invalid type) because I don't want to assume any specific way is the best way.
+
+## Drawbacks
+Implementing this change would increase the physical size of Luau, which is antithetical to Luau's 'minimal size principle'.
+
+It may also be worth considering that because `math.round` has gone unchanged for so long, some users may be confused when seeing the new syntax.
+
+## Alternatives
+One alternative could be to introduce a new function in the `math` library specifically for rounding to decimal places.
+```lua
+-- imagine 'todec' means 'to decimal [precision...?]'
+print( math.todec(3.1415, 2) ) -- Output: 3.14
+```
+The problem with this approach is that it's a rather unnecessary cluttering of the `math` library, especially in comparison to the proposed, much simpler solution. While they both achieve the same thing, this approach feels like it 'takes up too much space'.
+
+Another alternative could be to continue doing nothing. My only argument against not changing is that I think there's nothing to lose by making the change, however, I recognize that that's largely my personal bias, and that it may also be, in some ways and to some extent, an uneducated take.