Quorum

Four calls carry
the product.

Every Sibyl Memory read and write in this project is in one file, quorum/memory.py. Four call sites carry the whole product.

The deletion test

Once a pattern is confirmed, the swarm recognises that idiom on sight in a completely different contract, in a completely different session, from a single sighting.

Rather than assert an answer, Quorum ships it as a runtime flag. NoMemory implements the identical interface and forgets everything the instant it is written.

Same swarm, same contracts, memory removed. Every claim succeeds, so agents duplicate work. Every sighting looks like the first, so corroboration never accumulates and quorum is never reached. Retirements do not stick.

The same behaviour is asserted in tests/test_quorum.py.

A pattern is confirmed once

Recognising it in a later contract adds to its provenance rather than rewriting it: the swarm never loses the record of where it originally paid for this knowledge.

The deletion test on the front page shows the other half: with NoMemory, confirmed findings are 0 and recalled is 0.

Memory on

the recordthe shadow
$ quorum run --targets fixtures/VulnerableVault.sol fixtures/OpenFeeSetter.sol
  QUORUM    VulnerableVault.sol:withdraw   reentrancy   corroborated by callorder-lens, guard-lens
  QUORUM    OpenFeeSetter.sol:setFeeRate   unguarded-state-write   corroborated by modifier-lens, sender-lens
scanned 12 lens-units | confirmed 2 | recalled 1 | candidates 5

# new process, new day, contracts it has never seen. Real verified Base mainnet source
$ quorum run
recalled before reading any code: 2 confirmed pattern(s)
  RECALLED  FriendtechSharesV1.sol:buyShares   reentrancy
            first confirmed on VulnerableVault.sol   (1 sighting was enough)
scanned 24 lens-units | confirmed 0 | recalled 1 | candidates 11

Memory off

the recordthe shadow
# same swarm, same contracts, memory removed
$ quorum run --no-memory
scanned 24 lens-units | confirmed 0 | recalled 0 | candidates 12
nothing was confirmed, recalled or suppressed: without memory the swarm
cannot corroborate, recognise or forget.

What counts as the same idiom

A signature hashes the idiom on a line, not the identifiers on it. That is what lets a pattern the swarm confirmed on one contract be recognised in a completely different one. Receiver and argument names collapse, the method name survives, and the target of a write keeps its class.

msg.sender.call{value: amount}("") and protocolFeeDestination.call{value: protocolFee}("") are the same idiom and hash the same. weth.deposit{value: amountETH}() is a different idiom and does not.

quorum recall

REFERENCE tier
$ quorum recall

confirmed patterns (REFERENCE tier)
  reentrancy             reentrancy:97d18d17cfa4494a
    first confirmed on VulnerableVault.sol by callorder-lens, guard-lens
    recognised since on FriendtechSharesV1.sol  (1 sighting each, no quorum needed)

Where memory is load-bearing

TierWhat breaks without itWritten atRead at
HOT state/Agents duplicate each other’s work. A lens claims a (contract, lens) unit; a peer that finds it claimed does not scan it. This is the only coordination mechanism in the system.claim_worksame call
WARM entities/Quorum can never be reached. Corroboration is accumulated across lenses, processes and sessions on the finding entity. A lens has no idea who else agreed with it; memory does.record_sightingswarm.py:74
REFERENCE reference/Nothing is ever recognised again. A confirmed idiom becomes permanent swarm knowledge and is matched on sight in later sessions, on contracts the swarm has never read.promoteknown_patternswarm.py:79
ARCHIVE archive/Human corrections evaporate. Retire a finding once and no later session reports that shape again.retireis_retiredswarm.py:64

Every sighting, promotion, suppression and on-chain claim is also appended to the COLD journal, which is what makes a published claim auditable after the fact.

Coordination without a message bus

HOT tier
$ quorum swarm --workers 3

3 agent processes, one memory, no message bus
  agent-1   scanned   9  stood down on  15 units a peer had already claimed
  agent-2   scanned   7  stood down on  17 units a peer had already claimed
  agent-3   scanned   8  stood down on  16 units a peer had already claimed

  24 units scanned in total, 48 skipped, in 0.7s
  no agent sent a message to any other agent. The HOT tier decided who did what.

Three processes, one memory

Quorum’s agents are separate operating-system processes. They share one memory file and nothing else: no queue, no broker, no RPC between them. Three processes, twenty-four units of work, each done exactly once.

Claiming is optimistic because a read-then-write across processes is not atomic: an agent writes its own id into the claim, waits out the window in which a peer could be writing too, then reads the claim back and stands down unless it sees itself. Take the HOT tier away and all three agents do all twenty-four units.

PreviousThe lensesNextThe registry