diff --git a/text/0060-hkts.md b/text/0060-hkts.md
new file mode 100644
index 00000000..b212a346
--- /dev/null
+++ b/text/0060-hkts.md
@@ -0,0 +1,50 @@
+- Feature Name: higher kinded types
+- Start Date: 2018-11-11
+- RFC PR:
+- Pony Issue: 
+
+# Summary
+
+Higher kinded types (HKTs) are a way to refer to generic types which are themselves generic.
+
+# Motivation
+
+By supporting HKTs, Pony code could be made more generic by defining interfaces that support HKTs instead of concrete polymorphic types. This allow for strong static functional programming using Pony.
+
+# Detailed design
+
+Implementation of HKTs would likely be based on the Scala implementation. An example usage in Pony may be:
+
+```
+interface Functor[F[_]]
+  fun map[A, B](f: {(A): B}, fa: F[A]): F[B]
+```
+
+It seems like `[_]` could reference to any `_: Any val`.
+
+# How We Teach This
+
+Luckily, HKTs are pretty familiar to people using functional programming and are potentially transparent to those not using it. As such, reusing terminology is possible.
+
+The guides, especially those which discuss generic types, would need to be reworked. This should be as simple as introducing generic types which also have generic parameters.
+
+# How We Test This
+
+If Pony internals can be ported to use HKTs, this indicates an acceptance criteria. Inspiration can be taken from [typelevel Scala libraries](https://typelevel.org/projects/) with support for HKT.
+
+# Drawbacks
+
+Why should we *not* do this? Things you might want to note:
+
+tl;dr: scary for users and maintainers
+
+If this is accepted, it could (and perhaps should) be used throughout the implementation of Pony to write more generic code. This is risky. It also can make the code (on first blush) a bit more opaque to those not familiar with HKTs.
+
+
+# Alternatives
+
+By not integrating HKT support, we would need to write more concrete code. More code means more bugs and more maintenance. 
+
+# Unresolved questions
+
+None