update nomenclature

Updated naming conventions + now accurately refer to a tx record rather than a fee schedule to (hopefully) address Paul Madsen's feedback

"Hey @cooper_kunz the HIP uses 'fee schedule' to (inaccurately) refer to a tx record. More accurate would be to define a 'token fee schedule', which would be the fee policy requirements as listed in the token itself" -  - https://twitter.com/paulmadsen/status/1394624784600866823

HIP/hip-0000-custom-hedera-token-service-fees.md

@@ -13,7 +13,7 @@ We propose adding a limited set of functionality to the Hedera Token Service (HT
 ## Motivation
 In order to build a robust and sufficiently decentralized ecosystem, where no single entity can control community fees, or otherwise, developers need to be able to programmatically define and control fee relationships between various tokens issued on Hedera. Currently, the Hedera Token Service allows developers to easily configure, issue, and administer various types of cryptocurrencies, or tokens ([5](https://hedera.com/hh_tokenization-whitepaper_v2_20210101.pdf)).  However, there is currently very limited programmability, and HTS is not supported within Hedera Smart Contracts ([6](https://docs.hedera.com/guides/docs/sdks/tokens/define-a-token)), nor implemented within a layer 2 application/business network running on the Hedera Consensus Service ([7](https://github.com/hashgraph/hedera-improvement-proposal/issues/33)). 
 
-In practice, this may look something like creating a “protocol” or “ecosystem” token for a given service. The ecosystem may have dozens, or potentially hundreds of “related” or “sub” tokens, generated by different entities. By defining a custom token relationship (fee schedule) for each of the related tokens at the time of its creation, we can guarantee that the protocol or ecosystem token is able to capture value and distribute it trustlessly to various ecosystem participants. Without this functionality there is no true “on-chain”, or in Hedera’s case, “on ledger”, way to ensure that all future transactions of a given token are associated with a protocol or native token, or similarly royalties for an NFT are going to the appropriate party.
+In practice, this may look something like creating a “protocol” or “ecosystem” token for a given service. The ecosystem may have dozens, or potentially hundreds of “related” or “sub” tokens, generated by different entities. By defining a custom token relationship (i.e. a token fee schedule) for each of the related tokens at the time of its creation, we can guarantee that the protocol or ecosystem token is able to capture value and distribute it trustlessly to various ecosystem participants. Without this functionality there is no true “on-chain”, or in Hedera’s case, “on ledger”, way to ensure that all future transactions of a given token are associated with a protocol or native token, or similarly royalties for an NFT are going to the appropriate party.
 
 To provide a concrete example, there may be a protocol token called $PROTOCOL_GAS, which is required to be held by everyone participating in an ecosystem. Any tokens created within this ecosystem can have various amounts of $PROTOCOL_GAS, attached to them. So in order to send {protocol-token-1} to a user, they could, for example, attach 1 $PROTOCOL_GAS token to send to {entity-1}, 2 $PROTOCOL_GAS tokens to {entity-2}, and 3 $PROTOCOL_GAS tokens to {entity-3}, then each entity, e.g. a DAO, can do whatever they wish with the fees accumulated. 
 
@@ -54,14 +54,14 @@ TokenInfo:
 Note: see the reference implementation section for more details.
 
 ## Backwards Compatibility
-There are no known backwards compatibility issues. All tokens defined on HTS at the time of this implementation could retain their current fee schedules and be processed by the network, mirror nodes, etc. as if they were tokens created without custom relations or fee schedules. 
+There are no known backwards compatibility issues. All tokens defined on HTS at the time of this implementation could retain their current transaction record structure and be processed by the network, mirror nodes, etc. as if they were tokens created without custom token fee schedules. 
 
 For future compatibility with this issue there are changes that will be required to the Hedera Mirror Nodes, on and off ramps, SDKs, wallets, and applications that are looking to support HTS assets with custom token fees.
 
 ## Security Implications 
-This shouldn’t necessarily change security implementations not already known by Hedera’s current fee schedule structure and implementation. 
+This shouldn’t necessarily change security implications not already known by Hedera’s current fee model and transaction record structure/implementation. 
 
-However, there is a potential additional DDoS vector which can and should be addressed with limitations to the number of custom fees per token issued on HTS, as well as additional HBAR related fees for token transactions requiring a custom defined fee schedule, and associated more computationally expensive operations. 
+However, there is a potential additional DDoS vector which can and should be addressed with limitations to the number of custom fees per token issued on HTS, as well as additional HBAR related fees for token transactions requiring a custom defined token fee schedule, and associated more computationally expensive operations. 
 
 
 ## How to teach this
@@ -71,7 +71,7 @@ So similarly to how users might currently experience an insufficient transaction
 
 ## Reference implementation
 
-Current fee schedule:
+Current transaction record:
 ```
 {
   "signatures": [],
@@ -179,7 +179,7 @@ Current fee schedule:
 }
 ```
 
-Example of a new fee schedule:
+Example of a new transaction record:
 ```
 {
   "signatures": [],
@@ -326,7 +326,7 @@ new TokenCreateTransaction()
 
 In this example, the token created would require 100 tokens with entity ID 0.0.987 to be transferred into the account with entity ID 0.0.123. Account 0.0.123 could obviously be a single individual’s account, or it could be a multisignature account managed by an HCS based validator network, as we’ve recently seen in Greg Scullard’s NFT auction demo ([10](https://www.youtube.com/watch?v=hCPXKR1e7Ro)).
 
-This could be expanded to include multiple custom fees per token, up to the 6kb transaction limit imposed by the Hedera network as it currently stands ([11](https://docs.hedera.com/guides/docs/hedera-api/consensus-service/consensussubmitmessage#consensussubmitmessagetransactionbody)), or another threshold determined to help reduce the potential of a DDoS attack on the network through bloated token fee schedules.
+This could be expanded to include multiple custom fees per token, up to the 6kb transaction limit imposed by the Hedera network as it currently stands ([11](https://docs.hedera.com/guides/docs/hedera-api/consensus-service/consensussubmitmessage#consensussubmitmessagetransactionbody)), or another threshold determined to help reduce the potential of a DDoS attack on the network through bloated custom token fee schedules.
 
 ```
 new TokenCreateTransaction()
@@ -364,7 +364,7 @@ new TokenCreateTransaction()
 	.execute(client)
 ```
 
-If the token relationship or fee ID is defined as empty, or null, then the custom fee is applied to the token that is being created (because there isn’t yet an entity ID by which we can refer to it). If there are not enough tokens, or those tokens are not sufficiently divisible, then an error for “insufficient custom token transaction fee” (or something similar) would be thrown. It would be on the user transacting to go out and accumulate enough tokens in their wallet to successfully execute the transaction with the defined custom token relationships or fee schedules. 
+If the token relationship or fee ID is defined as empty, or null, then the custom fee is applied to the token that is being created (because there isn’t yet an entity ID by which we can refer to it). If there are not enough tokens, or those tokens are not sufficiently divisible, then an error for “insufficient custom token transaction fee” (or something similar) would be thrown. It would be on the user transacting to go out and accumulate enough tokens in their wallet to successfully execute the transaction with the defined custom token fee schedules. 
 
 ```
 new TokenCreateTransaction()