Protocol Proposals

Network throttling and fee management

Make the fee specified in a transaction a max amount the user will pay

https://github.com/stellar/stellar-protocol/issues/133

Update "surge pricing" to be more fair

https://github.com/stellar/stellar-protocol/issues/75

Stronger network semantics

Enabling invariants at the protocol level

https://github.com/stellar/stellar-protocol/issues/125

Base reserve requirement for data fields is not sufficient for preventing the bloat

https://github.com/stellar/stellar-protocol/issues/112

Order book improvements

CoSigned Assets

https://github.com/stellar/stellar-protocol/issues/146

Expiring offers

https://github.com/stellar/stellar-protocol/issues/175

Indivisible Assets

https://github.com/stellar/stellar-protocol/issues/113

Allow buy offers

https://github.com/stellar/stellar-protocol/issues/180

Payment channels and other "smart contracts"

Signatures or preauthorizations specifying flexible sequence numbers (so order doesn't matter)

https://github.com/stellar/stellar-protocol/issues/88

Ability to create accounts with predefined signers and predictable sequence numbers

https://github.com/stellar/stellar-protocol/issues/99

Non-atomic operations

It would be helpful if there were a way to have a single failed Payment operation (because the destination account does not exist) or failed CreateAccount operation (because the account already exists) not cause all other operations to fail.

Improve Issuer Experience

Allow sending account to add trustline on receiving account

https://github.com/stellar/stellar-protocol/issues/188