diff --git a/zip-1014.rst b/zip-1014.rst
index 247ae429..0de7e16c 100644
--- a/zip-1014.rst
+++ b/zip-1014.rst
@@ -24,13 +24,26 @@ Terminology
 The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY"
 in this document are to be interpreted as described in RFC 2119. [#RFC2119]_
 
+The term "network upgrade" in this document is to be interpreted as
+described in ZIP 200. [#zip-0200]_
+
+The terms "block subsidy" and "halving" in this document are to be interpreted
+as described in sections 3.9 and 7.7 of the Zcash Protocol Specification.
+[#protocol]_
+
+"Electric Coin Company", also called "ECC", refers to the Zerocoin Electric
+Coin Company, LLC.
+
+"Zcash Foundation", also called "ZF", refers to the 501(c)(3) nonprofit
+corporation of that name.
+
 
 Abstract
 ========
 
 This proposal describes a structure for the Zcash Development Fund, to be
 enacted in Network Upgrade 4 and last for 4 years. This Dev Fund would consist
-of 20% of the block rewards, split into 3 slices:
+of 20% of the block subsidies, split into 3 slices:
 
 * 35% for the Electric Coin Company;
 * 25% for Zcash Foundation (for internal work and grants);
@@ -46,7 +59,7 @@ Motivation
 ==========
 
 Starting at Zcash's first halving in October 2020, by default 100% of the block
-rewards will be allocated to miners, and no further funds will be automatically
+subsidies will be allocated to miners, and no further funds will be automatically
 allocated to research, development, and outreach. Consequently, no substantial
 new funding may be available to existing teams dedicated to Zcash: the Electric
 Coin Company (ECC), the Zcash Foundation (ZF), and the many entities funded by
@@ -116,7 +129,7 @@ Dev Fund allocation
 -------------------
 
 Starting at the first Zcash halving in 2020, until the second halving in 2024,
-20% of the block rewards SHALL be allocated to a "Dev Fund" that consists of
+20% of the block subsidies SHALL be allocated to a "Dev Fund" that consists of
 the following three slices:
 
 * 35% for the Electric Coin Company (denoted **ECC slice**);
@@ -236,7 +249,7 @@ are not accepted and disbursed by ZF, but rather directly assigned to the
 grantees. Thus, the following mechanism MAY be used in perpetuity for some
 or all grantees, if agreed upon by both ECC and ZF before NU4 activation:
 
-Prior to each Network Upgrade, the Foundation SHALL publish a list of
+Prior to each network upgrade, the Foundation SHALL publish a list of
 grantees' addresses and the total number of Dev Fund ZEC per block they
 should receive. ECC and ZF SHALL implement this list in any implementations
 of the Zcash consensus rules they maintain. This decision will then be,
@@ -360,7 +373,9 @@ References
 ==========
 
 .. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
+.. [#protocol] `Zcash Protocol Specification [Overwinter+Sapling+Blossom] <protocol/protocol.pdf>`_
 .. [#osd] `The Open Source Definition <https://opensource.org/osd>`_
+.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
 .. [#zip-1003] `20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate <zip-1003.rst>`_
 .. [#zip-1010] `Compromise Dev Fund Proposal With Diverse Funding Streams <zip-1010.rst>`_
 .. [#zip-1011] `Decentralize the Dev Fee <zip-1011.rst>`_