Contract lifecycle - Neuro Developer Documentation

States

State	Meaning	Normal next states
`Proposed`	Awaiting review and approval	Approved, Rejected
`Rejected`	Incomplete, inconsistent, or faulty	Proposed after creator update
`Approved`	Reviewed; can act as a template or begin signing	BeingSigned
`BeingSigned`	At least one signature exists but required roles are incomplete	Signed, Failed
`Signed`	All required role counts are satisfied; legally binding	Failed, Obsoleted
`Failed`	Obligations failed or provider marked it failed	Terminal by policy
`Obsoleted`	Explicitly superseded/retired	Terminal
`Deleted`	Deleted by owner/provider under allowed rules	Terminal

The server owns lifecycle enforcement. A client must treat a successful API response and the returned state as authoritative rather than updating local state optimistically. The sandbox processes new proposals automatically; operators are responsible for approval on other Neurons. Approval and party signatures remain separate lifecycle steps.

Typical flow

Event handling

Persist the contract ID, state, update timestamp, and last processed event ID. Notifications can be duplicated or arrive after a reconnect, so handlers must be idempotent and should re-fetch the contract before taking an irreversible action.

Visibility

Visibility	Retrieval/search behavior
`CreatorAndParts`	Creator and named parts only
`DomainAndParts`	Creator, parts, and accounts on the provider domain
`Public`	Anyone with the ID can retrieve; not searchable
`PublicSearchable`	Public retrieval and search

Visibility is not a substitute for parameter protection. Do not put secrets in a public contract.