We originally wanted to index a note within the execute function of the FlexSigning contract as a means of letting on-chain indexers query for context on a transaction. We were not aware that strings in event logs could not be fuzzy matched as strings are a variable length and require hashing to be emitted as an event, therefore exact matches are needed to find the hash.
We still want to provide context for the transaction as to let off-chain indexers like the Graph fuzzy match for the string, but we don't need to index the note and instead we will be storing the note in the data property.
The note will be the first 44 characters (arbitrarily chosen, but any variable length adds gas) of the check title. If the checkbook is private then we don't want to expose the context and instead will pass an empty string to the function signature. See this comment for the TODO context.
Personally, I think we should publish the first X characters for users instead of having them choose to remove decision overhead from the user and to ensure consistent context for public txns.
Motivation & Context
Breakdown of gas prices w/ sample prices
We don't really care about the price of contracts being deployed because we as in Station will be deploying the contract as a one time thing.
Note - it's actually cheapest for the user if we had function overloading, but at peak prices they would only be saving ~$1-2 per transaction, which could be significant if people were executing something like 100+ transactions at a time.
Steps to test
Create new checkbook with the updated contract
Create, approve, and execute the check
Check the check's transaction and view the event logs in the log's tab
The relevant log is the last one in the list. The new parameter isn't indexed so you can check the data and convert it to text to reveal the url for the check
Check the url to verify that it's showing the correct json for the check.
This pr updates the contract address constant to the new contract. The new contract includes an additional parameter in the event log of the execute function to provide context of the txn. The change is included in this pr.
The additional parameter is called note and the purpose is to allow the caller of the function to add a url where users can then check the url to determine more details about the check (or action) that was transacted.
This note parameter is of type string and is not strictly enforceable to be a url. Aka the caller of this contract could just add any kind of string here if they so wished 😀.
This pr also includes a sample api route to check the metadata of the transaction. Currently, it's logging the entire check object, but we might want to render this information conditionally depending on the user's privacy settings in the new app.
Motivation & Context
Adding the url param allows us and other apps who might potentially use the checkbook contracts to dynamically update the metadata of the executed transaction.
The gas for this implementation was 927,423 ⛽️.
Other possible implementations include:
Function overloading - (adding a duplication function with an extra param to allow for optionality) 1,040,951 ⛽️
Adding an extra param to every contract - 919,641 ⛽️
Adding an extra param with a default message appended in the contract - 944,668⛽️ (potentially helps querying)
The current implementation is neither the most expensive or least expensive (trivially) but allows for the most flexibility.
Steps to test
Create new checkbook with the updated contract
Create, approve, and execute the check
Check the check's transaction and view the event logs in the log's tab
The relevant log is the last one in the list. The new parameter isn't indexed so you can check the data and convert it to text to reveal the url for the check
Check the url to verify that it's showing the correct json for the check.
What's included in this pr + description
We originally wanted to index a note within the execute function of the
FlexSigning
contract as a means of letting on-chain indexers query for context on a transaction. We were not aware that strings in event logs could not be fuzzy matched as strings are a variable length and require hashing to be emitted as an event, therefore exact matches are needed to find the hash.We still want to provide context for the transaction as to let off-chain indexers like the Graph fuzzy match for the string, but we don't need to index the note and instead we will be storing the note in the
data
property.The note will be the first 44 characters (arbitrarily chosen, but any variable length adds gas) of the check title. If the checkbook is private then we don't want to expose the context and instead will pass an empty string to the function signature. See this comment for the
TODO
context.https://goerli.etherscan.io/tx/0x6a157886c20e93a8bae2797b31c53d394bd676d57f5c1bd54c95c0730b11b60d#eventlog
Personally, I think we should publish the first X characters for users instead of having them choose to remove decision overhead from the user and to ensure consistent context for public txns.
Motivation & Context
Breakdown of gas prices w/ sample prices
We don't really care about the price of contracts being deployed because we as in Station will be deploying the contract as a one time thing.
44 character note = 87,552 ⛽️ 21.1 gwei 1e-9 * 1560.56 = $2.88 ex)
execute(safe, …, note = check.data.title)
Empty string = 69,533 ⛽️ 21.1 gwei 1e-9 * 1,560.56 = $2.289 ex)
execute(safe, …, note = "")
No arg = 68,286 ⛽️ 21.1 gwei 1e-9 * 1560.56 = $2.248 ex)
execute(safe, … )
Note - it's actually cheapest for the user if we had function overloading, but at peak prices they would only be saving ~$1-2 per transaction, which could be significant if people were executing something like 100+ transactions at a time.
Steps to test
Screenshots and/or loom video
Relevant docs
Related pr https://github.com/0xStation/checkbook-contracts/pull/3 https://www.notion.so/0xstation/Gas-Estimations-7d0a2ba3c3a046ef853a42da3a812565#485ade813b7f489b825d68509e4af389
⬇️⬇️⬇️⬇️⬇️ [ARCHIVE BELOW] ⬇️⬇️⬇️⬇️⬇️
What's included in this pr + description
This pr updates the contract address constant to the new contract. The new contract includes an additional parameter in the event log of the execute function to provide context of the txn. The change is included in this pr.
The additional parameter is called
note
and the purpose is to allow the caller of the function to add a url where users can then check the url to determine more details about the check (or action) that was transacted.This
note
parameter is of type string and is not strictly enforceable to be a url. Aka the caller of this contract could just add any kind of string here if they so wished 😀.This pr also includes a sample api route to check the metadata of the transaction. Currently, it's logging the entire check object, but we might want to render this information conditionally depending on the user's privacy settings in the new app.
Motivation & Context
Adding the url param allows us and other apps who might potentially use the checkbook contracts to dynamically update the metadata of the executed transaction.
The gas for this implementation was 927,423 ⛽️.
Other possible implementations include:
Function overloading - (adding a duplication function with an extra param to allow for optionality) 1,040,951 ⛽️
Adding an extra param to every contract - 919,641 ⛽️
Adding an extra param with a default message appended in the contract - 944,668⛽️ (potentially helps querying)
The current implementation is neither the most expensive or least expensive (trivially) but allows for the most flexibility.
Steps to test
Screenshots and/or loom video
Log: https://goerli.etherscan.io/tx/0x8aaa8b11b4396ee7bd8813e18079b4ed31fe99393eebaadab1b8124efbae623b#eventlog
Metadata url
Outstanding issues
Relevant docs
Related pr https://github.com/0xStation/checkbook-contracts/pull/3 https://www.notion.so/0xstation/Gas-Estimations-7d0a2ba3c3a046ef853a42da3a812565#485ade813b7f489b825d68509e4af389