Core Definition:
A signal is comprised of input
information, which must be formatted into an admissible input map
. This information then performs atomic state updates
, with further side effects which may in turn generate new inputs
which may repeat the process. As an item of state, the admissible input map
may itself be mutated by state updates.
Signals are the core functional unit of many systems in blockchain, including:
The systems above have implementations which, because of not sharing fundamental signaling primitives, cannot easily interoperate, creating walled gardens within a shared problem space. By axiomatizing signals, we hope to enable greater interoperability and adoption of shared modular primitives within the onchain signaling space.
This level of abstraction creates 'signaling legos' which can be composed into bespoke implementations which retain readability and composability across different implementations which utilize the same underlying logic.
Furthermore, similar underlying signaling types and logics will allow for interoperability between different signaling systems.
A signal can be represented by information stored in a bytes
array. Particular methods of decomposing the bytes array into different data types can be accomplished by inheriting opinionated signaling instantiations.
Thus we can create a system in which:
Sigaling Entity
packages their Signal
into bytes, which is sent as transaction calldata to a Signal Processing
contract which processes the signal, updating the Signalling State
as well as automatically firing any second order Post-Signalling Computations.
ISignalType -> SignalType
Composable via Signal Processing Legos
Access control & weighting logic
pre & post-computation
side effects
Metadata store
Signal Store Monolith Hub
A) Ideal adoption would mean at least: a dozen or so different orgs using it for signal streams, additional modules created (and by devs other then myself) to extend signal stream capabilities and front end views, signal capture inherited to other live systems (ie. triggering dao treasury payments)
B) the idea is to streamline signalling to make it more modular and with quicker devtime turnaround. Most other projects I see are built in a very bespoke manner, and not for extensibility
C) the variety of interest from different usecases interests me, ie. treasury management from dxdao, payment coordination from coordinape, general dao management from collablanddao and general interest in using it for social signal collection
D) started as a passion project to attempt better coordination in a small social setting, still is mostly as there is no clear and explicit revenue model as of yet, but I'm mostly motivated about the potential for it to become a widely used tool in the dgov/chainsignalling world