Jake C-T
Jake C-T
### Problem The `feeReceiver` script in https://github.com/thehubbleproject/hubble-contracts/pull/636 has a number of edge/reuse cases where it will not work as effectively as it could, including things like checking for an existing...
See https://github.com/thehubbleproject/hubble-contracts/pull/621#discussion_r670416099 ### Problem Currently, when determining the next token to pack, the value of all pending tokens in a queue is considered even though only 32 (`MAX_TXS_PER_COMMIT`) of them...
### Problem When an unhandled promise rejection occurs in the Hubble Node process (and likely any of our scripts/other entry points), a warning is logged out but does not prevent...
After we have a public testnet active, we should add ourselves to a list of other L2 projects https://github.com/l2beat/l2beat/blob/master/CONTRIBUTING.md
### Problem Currently, we consider all L1 transactions valid after 1 confirmations. In mainnet scenarios, this is rather naive and we need to wait for additional confirmations. Relevant discussion: https://ethereum.stackexchange.com/questions/319/what-number-of-confirmations-is-considered-secure-in-ethereum...
### What's wrong When running the full test suite via `npm run test`, some tests will fail. ```sh $ npm run test ... 145 passing (6m) 2 pending 5 failing...
### What's wrong When a proposer is running, it will have a list of tokenIDs to stateIDs indicating where transaction fees are sent. However, if a new token is registered...
### What's wrong As we build out our REST HTTP RPC API, there are likely to be security issues/vulnerabilities that can be exploited. We need a good general way we...
### What's wrong When running a `create2Transfer` (c2t) that includes recipients that have no public key (pubkey), a coordinator needs to submit public key registrations for the new keys before...