diff --git a/text/0016-extrinsic-ordering.md b/text/0016-extrinsic-ordering.md
new file mode 100644
index 0000000..f53c06d
--- /dev/null
+++ b/text/0016-extrinsic-ordering.md
@@ -0,0 +1,59 @@
+# RFC-0015: Extrinsic Ordering
+
+|                 |                                                                                             |
+| -------------- | --------------------------- |
+| **Start Date**  | August 12, 2023  |
+| **Description** | Generalize the order of extrinsics by adding an explicit `i8` *order*  to each extrinsic. |
+| **Authors**     | Oliver Tale-Yazdi |
+
+## Summary
+
+The current block authoring protocol is very rigid; it requires to first apply all inherents and then all transactions. This makes it impossible to have inherents at the end of the block, or mix transactions or inherents. The RFC proposes a way to generalize the order of extrinsics.
+
+## Motivation
+
+Longer motivation behind the content of the RFC, presented as a combination of both problems and requirements for the solution.
+
+## Stakeholders
+
+A brief catalogue of the primary stakeholder sets of this RFC, with some description of previous socialization of the proposal.
+
+## Explanation
+
+Detail-heavy explanation of the RFC, suitable for explanation to an implementer of the changeset. This should address corner cases in detail and provide justification behind decisions, and provide rationale for how the design meets the solution requirements.
+
+## Drawbacks
+
+Description of recognized drawbacks to the approach given in the RFC. Non-exhaustively, drawbacks relating to performance, ergonomics, user experience, security, or privacy.
+
+## Testing, Security, and Privacy
+
+Describe the the impact of the proposal on these three high-importance areas - how implementations can be tested for adherence, effects that the proposal has on security and privacy per-se, as well as any possible implementation pitfalls which should be clearly avoided.
+
+## Performance, Ergonomics, and Compatibility
+
+Describe the impact of the proposal on the exposed functionality of Polkadot.
+
+### Performance
+
+Is this an optimization or a necessary pessimization? What steps have been taken to minimize additional overhead?
+
+### Ergonomics
+
+If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for?
+
+### Compatibility
+
+Does this proposal break compatibility with existing interfaces, older versions of implementations? Summarize necessary migrations or upgrade strategies, if any.
+
+## Prior Art and References
+
+Provide references to either prior art or other relevant research for the submitted design.
+
+## Unresolved Questions
+
+Provide specific questions to discuss and address before the RFC is voted on by the Fellowship. This should include, for example, alternatives to aspects of the proposed design where the appropriate trade-off to make is unclear.
+
+## Future Directions and Related Material
+
+Describe future work which could be enabled by this RFC, if it were accepted, as well as related RFCs. This is a place to brain-dump and explore possibilities, which themselves may become their own RFCs.