I just tought that it might help people undestand how this pool works by making a summary of the pool operations in list form.

A) The pool maintains the following:
1. A share log.
2. A payout queue.
3. For each user, a record indicating their own personnal balance, their payout threshold, the date of their last payout and the date of their of their last account activity.
4. An offline wallet.

B) Initialization
1. The share log and the payout queue begin empty.
2. The personal balance of each miner is initialized at 0; and the date of their last payout and their last activity is initialized at the date they begun mining.
3. The payout threshold is chosen by each miner, if none is given, it defaults to 0.04194304 BTC.
4. The offline wallet begins empty.

C) Unit of accounting
1. The basic unit of accounting in Eligius is a "share". A share is 'worth' block_reward/bitcoin_difficulty. (At the time of writing this: 25 BTC/17 336 316 979 = 0.000 000 001 442 BTC)
2. The value of bitcoin_difficulty for a given share is the difficulty at the time the share was awarded. It does not change later when the bitcoin difficulty increases.
3. The value of block_reward, however, is always taken as the current block reward. So when the block reward will be cut in half in 2017, the 'value' of all the shares still in the share log will be halved.

D) When a user submits a miner share (a valid proof-of-work meeting the difficulty requirement of the pool, pdiff):
1. The pool adds to the top of the share log pdiff shares. These shares are identified as belonging to the miner who submitted them.

E) When the pool finds a block:
1. 25 BTC+Transaction fees worth of shares are removed from the top of the share log, and credited to their respective miners' record. Each miners who was credited at least one share has it's date of last activity updated to the time the block was found.
2. If a miner was payed out with the generation transaction of that block, the payed out amount is removed from it's personnal balance. The date of their last payout is updated to the moment the block was found.
3. The pool refreshes the payout queue, see below.

G) How the payout queue is built:
1. Each user records are checked. Miners whose personnal balance is above their payout threshold are put in the payout queue. Miners whose date of last activity is older that a month are also put in the payout queue.
2. The queued miners are sorted by the time of their last payout, the oldest first.
3. The pool then goes down the list and finds the last queued miner such as the total of the balance of all the miners above him (including him) stays below 25 BTC. All those miners are put in the generation transaction to be put in the next block the pool finds, to be payed the full amount of their balance.
4. If the payout queue does not contain 25 BTC worth of queued miners's balance, the exceeding amount is sent to the pool's offline address.
5. While the pool computes 1, 2 and 3 (it takes time), it makes the miner work on a simple block that would send all the generated amount to the pool's offline address, to not waste miner's work.

H) When the payout queue grows longer that a few hundred BTC:
1. The pool operator initiates a transaction with the bitcoins in the offline wallet, paying everybody in the payout queue (except those in the first block, so that miners still have something to work on) the full amount of their balance.
2. If a miner was payed out with the manual payout transaction, the payed out amount is removed from it's personnal balance. The date of their last payout is updated to the date the transaction was submitted.
3. The pool refreshes the payout queue.

I) When the Bitcoin network orphans a block found by Eligius.
1. Everything that was done when the pool found the block (see E) is completely reversed.
2. Safe mode is triggered, see below.

J) When the pool is in safe mode:
1. The pool works mostly as normal, meaning submitted share are recorded as belonging to their respective miners, and when a block is found, those shares are credited to the miners' balance.
2. However, the automatic payout by generation transaction are disabled: The pool will always mine to the offline wallet until the situation is checked by the pool operator, who'll do some sanity check to ensure everybody is receiving their due amount. If everything is OK, the pool will resume normal operation.
3. During safe mode, the payout queue and the stats displayed on the main site may of may not be correct.
4. Safe mode may be triggered by an orphaned block, but it may also be triggered when a checks built into the pool software fails for whatever reason, it is however usually benign, but better be safe that sorry.