From e7ed6a29efdd0325263b30ad49496dfa48d206c1 Mon Sep 17 00:00:00 2001
From: Philipp Gackstatter <philipp.gackstatter@iota.org>
Date: Fri, 10 Nov 2023 13:57:46 +0100
Subject: [PATCH] Update Metadata Feature

---
 tips/TIP-0038/tip-0038.md | 53 ++++++++++++++++++++++++++++++++-------
 1 file changed, 44 insertions(+), 9 deletions(-)

diff --git a/tips/TIP-0038/tip-0038.md b/tips/TIP-0038/tip-0038.md
index e2c585d99..ee1b1f042 100644
--- a/tips/TIP-0038/tip-0038.md
+++ b/tips/TIP-0038/tip-0038.md
@@ -800,13 +800,9 @@ protocol treats this metadata as pure binary data, it has no effect on the valid
 increases the required storage deposit. ISC is a great example of a higher-layer protocol that makes use of <i>Metadata
 Feature</i>: smart contract request parameters are encoded in the metadata field of outputs.
 
-#### Additional syntactic transaction validation rules:
-
-- An output with <i>Metadata Feature</i> is valid, if and only if 0 < `length(Data)` ≤ `Max Metadata Length`.
-
 <details>
   <summary>Metadata Feature</summary>
-  <blockquote>Defines metadata (arbitrary binary data) that will be stored in the output.</blockquote>
+  <blockquote>Defines a map of key-value pairs that is stored in the output.</blockquote>
 </details>
 <table>
   <tr>
@@ -826,12 +822,51 @@ Feature</i>: smart contract request parameters are encoded in the metadata field
     <td>Set to <strong>value 2</strong> to denote a <i>Metadata Feature</i>.</td>
   </tr>
   <tr>
-    <td>Data</td>
-    <td>(uint16)ByteArray</td>
-    <td>Binary data. A leading uint16 denotes its length.</td>
+    <td>Entries Count</td>
+    <td>uint8</td>
+    <td>The number of entries in the map.</td>
+  </tr>
+  <tr>
+    <td valign="top">Entries <code>anyOf</code></td>
+    <td colspan="2">
+      <details>
+        <summary>Metadata Entry</summary>
+        <blockquote>A map entry consisting of a string key and an arbitrary byte value.</blockquote>
+        <table>
+          <tr>
+            <td>
+              <b>Name</b>
+            </td>
+            <td>
+              <b>Type</b>
+            </td>
+            <td>
+              <b>Description</b>
+            </td>
+          </tr>
+          <tr>
+            <td>Key</td>
+            <td>(uint8)ByteArray</td>
+            <td>A string which may only consist of ASCII characters. A leading uint8 denotes its length.</td>
+          </tr>
+          <tr>
+            <td>Value</td>
+            <td>(uint16)ByteArray</td>
+            <td>An array of arbitrary binary data. A leading uint16 denotes its length.</td>
+          </tr>
+        </table>
+      </details>
+    </td>
   </tr>
 </table>
 
+#### Additional syntactic transaction validation rules:
+
+- Each `Key` in the `Entries` must consist only of bytes that are valid ASCII characters, that is, each byte may not
+  exceed `127`.
+- `Entries Count` must be at least `1`.
+- The serialized size of the feature may not exceed `8192` bytes.
+
 ### Tag Feature
 
 A <i>Tag Feature</i> makes it possible to tag outputs with an index, so they can be retrieved through an indexer API not
@@ -901,7 +936,7 @@ plugin.
   <tr>
     <td>Token ID</td>
     <td>ByteArray[38]</td>
-    <td>Identifier of the native token. Its derivation is defined in <a href='../TIP-0044/tip-0044.md#foundry-output'>TIP-44</a>.</td>
+    <td>Identifier of the native token. Its derivation is defined in <a href='../TIP-0044/tip-0044.md#foundry-output'>TIP-44 (Foundry Output)</a>.</td>
   </tr>
   <tr>
     <td>Amount</td>