The seed could be the hash of all transaction in the previous CB. You can't control the value of a hash, that's a major point of hashes: you can't find the content of a transaction which, when concatenated with the other transactions, will result in the given hash value. So you can't control the seed even if you control a part of the transactions.
You may not be able to control the seed, but you can see what the outcome will be with that seed, which means you can run it many times until you get something that you like. Hashing is a very cheap operation, cheaper still with server clusters targeting such activity. If you can see 4 billion futures, you only need to select the one that pleases you the most. So transaction activity can't be used for determining the next order.
Since there is no control of the random generator, you'll have to resort to bruteforcing it. In order to prevent that, I proposed fixing all the seeds completely and not using any "entropy" by your terms. While this complicates the attack significantly, it's still not bulletproof. Maybe it's easier to deal with the possibility of bruteforce search of a favorable seed. If the proportion of shares that you own is p, to have n consecutive TBs you'll have to enumerate (1/p)^n seeds. For n=360, an hour of disruption, and p=0.9, a 90% attack, you will need to enumerate 29695907506101728.772544490140544 seeds on average. We can live with that.
We can't predict the advancement of computing power, we
can limit the amount of currency available at any one point.
There is a clear issue I have been avoiding in regards to letting any kind of adjustable seed determine the next order which was the reason I wanted to use deterministic signatures originally and changed from the deterministic function idea that I did have as the earlier design-case. I do not want to go down that path yet because I do have potential solutions, and it does not have anything to do with SH security. But the less futures EvilCorp can see, the better.
In any case, Ed25519 can be required to be the SH signatory function. It has deterministic signatures, and these can be used to generate entropy. Without requiring a deterministic DSA, each SH could include a structure such as this { signature of CB hash, symmetric encryption key }, encrypted with symmetric encryption key. The encryption key is revealed in the next CB, and it is a verifiable, unpredictable entropy unless EC controls 100% of SHs. Even without deterministic signatures, EC is in the same situation where he must exclude his keys to change the order, and this will result in severe penalties and EC has only the limited number of futures equal to the number of shares he controls, and modifying it will cause him to lose money. But this introduces a significant delay...