---
# System prepended metadata

title: TX Builder 0.1.0

---

# TX Builder 0.1.0

Audit/Investigate: 
- [x] Follow TX lifecycle, examine what is DH specific, what is intrisic
- [x] Should we turn the arg type factory into a configurable factory? How much work is this? (No. Not yet)
- [x] What utils can be refactored into their domain specific libraries (cache, abi, tx-builder, mayber ethers)
- [x] What goofy patterns are left over from when we had to keep .env at the library/app level? 
- [x] ABI utils are pretty useful on their own. How should these be organized? Should devs really have to pull in all of tx-builder to use this? (Yes)
- [x] Is it possible to extract all ethers utils into library? (Yes)

## A Much Smaller Refactor

- [ ] Create ``cache-utils``
    - [ ] Rename CACHE_CONFIG to DH_CACHE
    - [ ] Remove centralized Store config var
    - [x] Create generic cache store function
    - [ ] create DAOhaus cache store
    - [x] Create decorated functions so that anyone can add to the store
    - [x] Create decorated functions so that anyone can access a store
- [x] Create``abi-utils`` 
    - [ ] Decorate caching functions for the abi store using DH store
    - [ ] Update all imports for each cache utils library
    - [ ] Pull abi specific caching from ``cache utils``
    - [ ] ContractLego types go here 
    - [ ] Rename to ABI legos
    - [ ] Create analogue ABI types
    - [ ] Processed contract utils could go here
- [ ] Remove ``moloch-v3-data`` from tx-builder
    - [ ] Create poll result data type based onPollSuccess 
    - [ ] create ``findTransaction`` inside of ``tx-builder``
    - [ ] create variable and return types for ``findTransaction``

## Improve Patterns
- [ ] Configurable Poll (currently its hardcoded) and test
- [ ] Configurable RPCs
- [ ] Do we use localAbis prop? If not remove it. 
- [ ] In decodeProposalActions Multicall Meta pattern is dependant on static data we may not have. What are we using this for? May not be able to refactor decoding to a static library if this is the pattern we have to use. 
- [ ] Discuss with Brian about wrapping Modal methods at the transaction level vs. at the formBuilder level. 
    - [ ] What should formBuilder control
    - [ ] What should TxBuilder control



### Did not work out


- [x] Create ``ethers-utils``
    - [x] utils/types/contracts => ethers-utils/types/abi
    - [x] Update all imports for above changes
    - [x] utils/utils/encoding => ethers-utils/utils/encoding
    - [x] Update all imports for above changes
    - [x] fromWei to formatting 
    - [x] Update all imports for above changes
    - [x] gas.ts from utils to ethers-utils
    - [x] Update all imports for above changes
    - [x] votingPowerPercentage, memberTokenBalanceShare, memberUsdValueShare, sharesDelegatedToMember, lowerCaseLootToken, checkHasQuorum from ``general.ts`` to ``moloch-v3-utils``
    - [x] Update all imports for above changes
    - [ ] toBaseUnits and toWholeUnits from ``utils`` to ``ethers-utils``
    - [ ] Update all imports for above changes
    - [ ] ``createContract`` in tx-builder to here
    - [ ] Move decoding.ts in ``tx-builder`` to here
        - [x] First, I have to discover if type data is stored in the encoded bytes array  
        - [ ] If it is, write a method that tests if the bytes data can be decoded this way
        - [ ] Then create a factory for handling bytes data (we should write one for multicall)
        - [ ] Test
        - [x] If not, see if it's possible to append an encoded indentifier and manually add the type data to the bytes
        - [x] Test
        - [ ] Create a way to find that identifier in the bytes data.
        - [ ] Then create a method to test for that indentifier
        - [ ] Create a method that splits the args from the arg types using the identifier
        - [ ] Create a method that hydrates the types and uses them to decode the arguments 
        - [ ] Add this into library and delete the former method for decoding arguments. 