According to the code:

/** percentage fields are fixed point with a denominator of 10,000 */                                                                                                                                                                       
#define GRAPHENE_100_PERCENT                                    10000                                                                                                                                                                       
#define GRAPHENE_1_PERCENT                                      (GRAPHENE_100_PERCENT/100)   

Before launch I went through every place in the witness_node where percentages are used and standardized most of them to use GRAPHENE_100_PERCENT.  I just now checked the code which handles the max force settlement, and it definitely uses these constants.  So 2000 definitely represents 20%.

You can see that it is currently set to 2000 for BitUSD (and I don't doubt for the other assets as well):

>>> get_asset USD
{
   ...
   "issuer": "1.2.0"
...
  "bitasset_data_id": "2.4.21"
}
>>> get_object 2.4.21
{
...
      "maximum_force_settlement_volume": 2000,
...
}

I can state with certainty that it is currently 20%.  It is possible to change with a committee proposal of asset_update_operation.

Great care should be taken on any such proposal to ensure the issuer permissions and flags have the same values as before.

Also on my wishlist for the API:  Generate a JSON blob representing full type information for each API call, which can be used to auto-generate language bindings for the API.

You can think of this as like splitting James's JSON operation serializer into a frontend which reflects all Graphene types, and a backend which outputs various useful JS code, such as a JS class for all C++ structs.  The frontend would then output a JSON blob which is taken by the backend.

I'm pretty sure JS language object model is sufficiently powerful that the backend could be completely written in JS as a generic library, which would take the JSON blob and construct the classes at runtime.  Python could be done similarly.

I'd like to allow plugins to define API calls, and configuration file options to specify which plugins to enable, and which plugins require login to access their API calls.

• It allows us to break the API up into smaller units.  Currently database_api is huge because we have to put everything accessible without login in there.
• It allows a path for API upgrade.  If the old API and new API are plugins which can be enabled / disabled by a specific site, then a site can upgrade the API on their schedule, not ours.
• It allows different security profiles.  For example, we could create a "HTTP plugin" which makes login and secure API calls of other plugins accessible over HTTP.  Sites that want to interface with the wallet over HTTP can use that plugin (and then it is on them to ensure the wallet is properly firewalled, containerised or otherwise isolated), while the default config has the plugin disabled for security reasons.

Related issues:  #245, #246, #422.

Btw, is it possible to lock BTS?

The chain has support for creating vesting balance objects, which allows you to lock any asset, and have a variety of unlocking parameters.

Core asset (i.e., BTS) VBO's are created for witness pay and the cashback functionality.

It doesn't really make economic sense to create a VBO, except in a multi-party transaction where one party is either the blockchain, or acting on behalf of the chain.  I personally like the idea of a worker proposal to pay people for locking up their BitAssets.  For example, if 10k BTS is worth $50, you could create a worker which is funded 10,000 BTS per day, with a business plan of buying $50 BitUSD every day at current market prices, then collecting offers from people based on how many BitUSD they are willing to lock up, and for how long, to get $X of worker's the BitUSD, and then paying out to the top offers in VBO's.  You'll always be able to fill it (I'm assuing somebody will always make an offer to be paid $50 to lock up $0.01 for five minutes, and then better offers will come in until the imputed yield gets comparable to any other fixed-income instrument, modulo transaction costs and the market's perception of the probability of certain risk factors unique to BitAssets, like BitUSD black swans or lost/hacked private keys.)  It's quite similar to a no-reserve government debt auction, and it seems like a decentralized autonomous fixed-income capability would be attractive to people in these times of zero interest rates.  I think this system is a superior replacement for the BTS 0.x yield system because you know what you're getting in advance.

Of course most people I've talked to (including other people here at Cryptonomex) all seem to hate my idea for some reason that they never clearly explain, but blockchain level support for it is there if I ever manage to convince anyone it's a good idea.

There are two deployed Graphene-based blockchains in production right now:  Bitshares 2 and Muse.  That number will only grow in the future.  For example, at some point we would like to create a demo network which will be like a testnet, but with interesting stuff like live price feeds and (maybe later) other interesting stuff like market bots.  As things stand now, I'm told it can be tough to get new users when the first thing they hear is "you have to buy lots of BTS to really experience the system."   With a demo net where none of the tokens have real value, we can give away the core token, so everyone can experience how awesome Graphene is and try some of the more advanced features like creating assets, without committing to buy anything until they're ready.

Anyway, we need a way to effectively manage features which may or may not be deployed on each of the branches.  To that end, we've moved to a new forking model:

https://github.com/cryptonomex/graphene/wiki/How-we-use-version-control

Be advised the master branch has been force-pushed, as I used the new forking model to help me make sure all the new features were properly tested for today's release, and there wasn't really a simple way to reconcile things without force-pushing to the master branch.  We'll try not to do this often on master (develop is another matter).

The single most important item for community contributors is to please base your commits on stable.

Release is available at https://github.com/peertracksinc/muse/releases/tag/v1.0.151101

All full nodes will need to upgrade to this release by Wed Nov 4 16:00:00 UTC 2015.

- Corrects an issue in the previous release that prevents `PARENT.CHILD` assets from being created #409
- Add the capability for asset owner to claim asset fees #413
- Allow asset issuers to blacklist some accounts from holding a particular asset while maintaining a "default accept" policy for other accounts #415

In addition, numerous bug fixes and wallet enhancements have been included, and reindexing performance has been improved.

Reindexing will be required, and should occur automatically.

@mike623317 : Every maintenance interval, we record the historical stats of the budget.  These can be accessed as objects 2.13.x.

The reserve is the sum of the three "from" fields, from_initial_reserve, from_accumulated_fees, from_unused_witness_budget.  It represents the overall inflation cap, i.e., the total number of the additional core asset (i.e., BTS) that will ever be able to come into existence.

The total_budget is the amount of core asset that can be allocated to workers or witness pay.  Depending on what the committee and voters do, up to total_budget can be spent; exceeding the total_budget would require a hardfork.

The total_budget is calculated as a tiny fraction of the reserve, specifically, 17 / 2**32 times the number of seconds in a maintenance interval, rounded up.  This number was chosen to initially give about the same rate of creating BTS as 101 delegates all with 100% pay in BTS 0.x.

witness_budget is how much is reserved for witness pay.  This is the time to next maintenance interval times witness pay.

worker_budget is how much is available for workers to be paid.  Witnesses have higher priority than workers.

leftover_worker_funds is how much is available for workers to be paid.

supply_delta is how much the supply changed due to fees and budget logic operation during this maintenance interval.  It does not include activities like manual reserve/burn of assets, or the operation of reserve/burn workers.

Right now there is one reserve worker, 1.14.0.  Like "normal" workers, the reserve worker is voted to receive BTS with the worker system; unlike "normal" workers, the chain itself forces a reserve worker to immediately return all of its funds to the reserve.  So the supply delta in budget_record_object misleadingly indicates the network is massively unprofitable, since it does not account for the fact that most of the BTS go to reserve400k and are burned returned to the reserve.  This needs to be fixed, and tracking of e.g. how much a worker has received needs to be implemented.