absolutebi/serai
1
0
Fork 0
mirror of https://github.com/serai-dex/serai.git synced 2025-12-08 12:19:24 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
e3e41324c923a80b67ce7580a21a9f0c4f57a4e6
serai/processor/ethereum/erc20/Cargo.toml

32 lines
1.0 KiB
TOML
Raw Normal View History

Smash ERC20 into its own library
2024-09-16 21:59:12 -04:00
[package]
name = "serai-processor-ethereum-erc20"
version = "0.1.0"
description = "A library for the Serai Processor to interact with ERC20s"
license = "AGPL-3.0-only"
repository = "https://github.com/serai-dex/serai/tree/develop/processor/ethereum/erc20"
authors = ["Luke Parker <lukeparker5132@gmail.com>"]
edition = "2021"
publish = false
Add Serai key confirmation to prevent rotating to an unusable key Also updates alloy to the latest version
2024-12-08 20:42:37 -05:00
rust-version = "1.81"
Smash ERC20 into its own library
2024-09-16 21:59:12 -04:00
[package.metadata.docs.rs]
all-features = true
rustdoc-args = ["--cfg", "docsrs"]
[lints]
workspace = true
[dependencies]
alloy-core 1.0, alloy 0.14, revm 0.22 (001) This moves to Rust 1.86 as were prior on Rust 1.81, and the new alloy dependencies require 1.82. The revm API changes were notable for us. Instead of relying on a modified call instruction (with deep introspection into the EVM design), we now use the more recent and now more prominent Inspector API. This: 1) Lets us perform far less introspection 2) Forces us to rewrite the gas estimation code we just had audited Thankfully, it itself should be much easier to read/review, and our existing test suite has extensively validated it. This resolves 001 which was a concern for if/when this upgrade occurs. By doing it now, with a dedicated test case ensuring the issue we would have had with alloy-core 0.8 and `validate=false` isn't actively an issue, we resolve it.
2025-04-12 08:09:09 -04:00
alloy-core = { version = "1", default-features = false }
Smash ERC20 into its own library
2024-09-16 21:59:12 -04:00
alloy-core 1.0, alloy 0.14, revm 0.22 (001) This moves to Rust 1.86 as were prior on Rust 1.81, and the new alloy dependencies require 1.82. The revm API changes were notable for us. Instead of relying on a modified call instruction (with deep introspection into the EVM design), we now use the more recent and now more prominent Inspector API. This: 1) Lets us perform far less introspection 2) Forces us to rewrite the gas estimation code we just had audited Thankfully, it itself should be much easier to read/review, and our existing test suite has extensively validated it. This resolves 001 which was a concern for if/when this upgrade occurs. By doing it now, with a dedicated test case ensuring the issue we would have had with alloy-core 0.8 and `validate=false` isn't actively an issue, we resolve it.
2025-04-12 08:09:09 -04:00
alloy-sol-types = { version = "1", default-features = false }
alloy-sol-macro = { version = "1", default-features = false }
Smash ERC20 into its own library
2024-09-16 21:59:12 -04:00
Fix clippy, update old dependencies
2025-08-25 09:17:29 -04:00
alloy-rpc-types-eth = { version = "1", default-features = false }
alloy-transport = { version = "1", default-features = false }
alloy-provider = { version = "1", default-features = false }
Don't have the router drop transactions which may have top-level transfers The router will now match the top-level transfer so it isn't used as the justification for the InInstruction it's handling. This allows the theoretical case where a top-level transfer occurs (to any entity) and an internal call performs a transfer to Serai. Also uses a JoinSet for fetching transactions' top-level transfers in the ERC20 crate. This does add a dependency on tokio yet improves performance, and it's scoped under serai-processor (which is always presumed to be tokio-based). While we could instead import futures for join_all, https://github.com/smol-rs/futures-lite/issues/6 summarizes why that wouldn't be a good idea. While we could prefer async-executor over tokio's JoinSet, JoinSet doesn't share the same issues as FuturesUnordered. That means our question is solely if we want the async-executor executor or the tokio executor, when we've already established the Serai processor is always presumed to be tokio-based.
2024-09-17 02:59:01 -04:00
Work on testing the Router Completes the `Executed` enum in the router. Adds an `Escape` struct. Both are needed for testing purposes. Documents the gas constants in intent and reasoning. Adds modernized tests around key rotation and the escape hatch. Also updates the rest of the codebase which had accumulated errors.
2025-01-23 01:59:24 -05:00
ethereum-primitives = { package = "serai-processor-ethereum-primitives", path = "../primitives", default-features = false }
Fix the async flow with the Router It had sequential async calls with complexity O(n), with a variety of redundant calls. There was also a constant of... 4? 5? for each item. Now, the total sequence depth is just 3-4.
2025-01-23 06:10:18 -05:00
futures-util = { version = "0.3", default-features = false, features = ["std"] }
Reference in New Issue Copy Permalink