List view
This is the 0.3.0 release. On Feb 17, we open up 0.3.0-beta to select partners. Track anything missing for this here, so we can pull together loose ends by EthDenver
No due date•2/2 issues closedTracking things we want for 0.4 release Main goals are clean full-stack (wavs, cli, template, docs) solutions for: - deploying on Holesky testnet - multi-workflow services (incl cron) - operator tooling (how to serve, manage keys, monitor/jaeger) - ~~rewards support (nice to have)~~ We can also add other DevX improvements as they come up
No due date•105/105 issues closedThe vision is WAVS existing as a layer over many chains: - Listening to events from many chains - Responding on many chains - Supporting both EVM and CosmWasm initially - Syncing operator sets between different chains so that tasks can be verified - Tests for multichain flows - Decent developer experience for building multichain flows
No due date•4/4 issues closedOnce we have the basic multi-operator flow working, with [Ethereum compatibility](https://github.com/Lay3rLabs/wasmatic/milestone/7) and [centralized aggregator](https://github.com/Lay3rLabs/wasmatic/milestone/3), let's check the APIs are extensible to other use cases, not just hello world. We need to find some other example contracts that are ideally more complex, and work to deploy the same contracts and port their operator to a simple WASI component. This may well require us to: - Update the trigger to get other data - Update the WIT and execution to pass other parameters to the wasm - Different signed message format / aggregation strategies Additionally, WAVS still should work with CosmWasm, we could use a few examples there leveraging Commitments or verifying results from an Eigenlayer secured AVS service (a stretch goal). We can use this to ensure the general system is as flexible as possible, but do not worry about adding super powers (like precompiles) to the WASI components yet.
No due date•3/6 issues closedThis works to get a **single operator** working on a local ethereum node and eignelayer contracts. We need https://github.com/Lay3rLabs/wasmatic/milestone/3 to aggregate multilple operators' results.
No due date•21/21 issues closedUse triggers no longer tied to one task queue. These can be events from any contract on layer chain. Or events on other chains. We need a way to provide deterministic unique ids for each trigger event per service. Possibly an ordering. Verifier contract checks this id was not used (and maybe some sequence). It also takes different action that writing to the task queue, doesn’t reference task queue specifically, only task queue is one possible implementation of an output handler This would allow the original format but also many others.
No due dateNodes use BLS signatures Still query chain directly for triggers, but don’t write to chain, rather sign special message. Store internally which triggers they have processed to avoid repeats Add aggregator service they post messages to, who combines signatures and who submits final tx on chain Requires a new contract on server side to handle the new aggregated signature Add more info…
No due date* Still query chain directly for triggers, but don’t write to chain, rather sign special message. * Add aggregator service they post messages to, who combines signatures and who submits final tx on chain * Target hello world eignelayer example * Only use secp256k1 aggregation, not bls signature aggregation Also check out https://github.com/Layr-Labs/eigensdk-rs?tab=readme-ov-file for other tools we might want to leverage at this point
No due date•5/5 issues closed- Allow creating services with multiple components and multiple triggers. - All sharing same state. - Update APIs - Add kvstore support and some permissioning around file system and kv access - Other enhancements to the core system, WASI capabilities
No due date•10/11 issues closedStable version with new types and architecture Same 0.1 feature set and api
No due date•30/31 issues closed