# Extensibe Signaling Primitive

## Signals

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:
* Governance
* Coordination
* Treasury Management
* Attestations
* General Memetics

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.

# Implementation

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.`


## Contract Infrastructure

### Signal Definition
ISignalType -> SignalType
### Signal Processing
Composable via Signal Processing Legos
Access control & weighting logic
pre & post-computation
side effects
Metadata store
### Signal Store
Signal Store Monolith Hub

## Scout Q&A
- Where do you see the product going over the next 12 months?
- How are you building ESP vs other attempts at on-chain signaling?
- Where is the most exciting experimentation in this happening currently? Which projects? What inspires you here?
- Is this a passion project? Or are the intentions to try to build ESP into a long term project?

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