From 18c5aca04a94f430919462865bbe824af9db9744 Mon Sep 17 00:00:00 2001
From: 0age <37939117+0age@users.noreply.github.com>
Date: Tue, 19 Nov 2024 09:39:50 -0800
Subject: [PATCH] Update README.md

---
 README.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 1d0e629..1b00313 100644
--- a/README.md
+++ b/README.md
@@ -732,5 +732,6 @@ The Compact is currently in _**Version 0**_ — this version is meant to serve a
 Candidate features for Version 1 to consider when reviewing or integrating with Version 0 include:
  - Revising the interface between The Compact and allocators — currently, allocators authorize claims via direct calls (i.e. arbiter == allocator), ECDSA signatures, or EIP-1271 `isValidSignature(bytes32 domainHash, bytes signature) external view` calls. This may prove overly restrictive for many use-cases, including fully onchain varieties of allocator (especially when the allocator and the arbiter are not the same entity). Alternatives to consider include a stateful callback and/or the use of transient storage to register key details concerning the claim so that allocators and other actors can access them when needed.
  - Revisiting function dispatch and reentrancy guard mechanics — in Version 0, function dispatch and standard solidity function ABI decoding consumes a significant amount of total gas expenditure and available contract size due to the sheer number of external functions supported. Furthermore, reentrancy guards are set and cleared on an as-needed basis, and not at the initial entrypoint to the contract. One alternative is to include a top-level fallback function with a global reentrancy lock and custom dispatch for processing claims or other external calls based on detected properties of the call.
+ - Modifying witness typestring mechanics — in Version 0, a witness typestring fragment is supplied that includes both the argument for the witness as well any additional types for the struct, if any, used by the witness. This gives some added flexibility, but also leads to additional data that needs to be supplied by the arbiter when calling The Compact and opens arbiters up to selecting structs with names that do not adhere to the requirement that all EIP-712 struct definitions are alphanumerically ordered in the typestring. By way of example, if a given witness uses a struct of `Witness(uint256 witnessArgument)`, the supplied typestring would be `Witness witness)Witness(uint256 witnessArgument)`. One option for Version 1 would be to define a fixed witness struct fragment internally and only allow for providing the internal arguments; given the provided example, the arbiter would simply provide `uint256 witnessArgument` for the witness typestring argument.
  - Reworking metadata — Version 0 implements relatively rudimentary metadata rendering. Version 1 should improve on this metadata, particularly as it relates to images and other rich metadata, without compromising on the core autonomy and reproducibility present in Version 0.
- - General optimization: Version 0 already contains a significant amount of low-level code in order to succintly represent the necessary logic. Version 1 could improve on overall efficiency by implementing further optimizations and by bringing the codesize down further to allow for dialing up compiler optimization.
\ No newline at end of file
+ - General optimization: Version 0 already contains a significant amount of low-level code in order to succintly represent the necessary logic. Version 1 could improve on overall efficiency by implementing further optimizations and by bringing the codesize down further to allow for dialing up compiler optimization.