Amendments

When running your own rippled node, there are some configuration options relating to amendments.

You can query a public server, such as s1.ripple.com, to see what the current state of the network is.

As an individual node, you don't have control over the network's enabled amendments. The enabled amendments are determined by votes from trusted validators (i.e., those on UNLs). Enabled Amendments are a property of the network, not a node. Any active amendment is always active across the entire network. You just need to run code the understands (has code for) the active amendments; otherwise your node will report that it's amendment blocked.

In other words, node operators do not enable amendments. Validators do - by proposing EnableAmendment pseudo transactions. Tx submission nodes are separate from validators.

If your node's purpose is to submit transactions to Mainnet, then there is no need for the [features] or [amendments] sections in rippled.cfg.

Typically, there is no need for rpc_startup either.

[features] and [amendments]

These sections can be useful when running independent test networks or using standalone mode. These are important for testing and debugging.

What are "Obsolete" amendments?

"Obsolete" amendments have had their conditional code removed. In some cases (like "Escrow"), this means the amendment is permanently enabled (and cannot be vetoed). In the "feature" API response, "enabled": false is misleading; the amendment could actually be permanently enabled, but retired. In other words, the code is always-on because the pre-amendment code has been retired.