Comparison to other APIs

Page Information

Page Completion	Valid as of	Notes
🟢 100%	Pre-release	None

Notes

• This page is written in our own opinion: it's completely valid that you may disagree with any of the thoughts we have.
• If you have any comments, suggestions and/or criticisms for this page, please do post them on this issue.
• Key: 🟢 = good, 🟡 = okay, 🟠 = bad, 🔴 = terrible. This is a score, not specifically an indicator on if a feature is included or not. For example, see Treasury's multi-world support comparison on the Economy API.

Economy API Comparison

Feature	Treasury	Vault	Comment
Adoption	🔴	🟢	Treasury is brand new, so we have no idea how much it will be adopted. Currently very little adoption has taken place for this reason.
Documentation (Wiki & javadocs)	🟢	🟡	Treasury has a great degree of documentation so server owners and developers can understand how to use it. Vault's documentation is.. okay, there is a good amount of room for improvement.
Time since release	🔴	🟢	Treasury: approx. early 2022. Vault: Oct 2011.
Stability	❓	🟢	Treasury is currently in pre-release development, so we are unable to compare stability of the API. It will only be determined with time. We are striving to keep a stable API by trying to do things right the first time.
Multi-platform	🟢	🔴	Vault is only operational on Bukkit, whilst Treasury's APIs are platform-independent.
Quality support	🟢	🔴	Vault's has pretty much no support. You can e-mail the maintainer to ask basic things and expect a reply in a few year's time.
Concurrency	🟢	🔴	Treasury uses a specialized EconomySubscriber class which can also be converted into a CompletableFuture. Vault has no concurrency support whatsoever. Concurrency support is important as an economy plugin may need to make a query to a database - when completed synchronously in Vault, it will freeze the server until the request is completed. Database queries are not instantaneous due to possible load at the time and connection speed if it is ran on a different server.
Willingness for change	🟢	🔴	If your proposed change to Vault breaks a plugin that hasn't been updated for 7 years, then forget it. Treasury will always strive to maintain some degree of legacy support, but we will not let it drag the project behind.
Non-Bloated APIs	🟢	🟢	Treasury and Vault are strictly against having bloated APIs.
Adoption of UUIDs	🟢	🟠	Vault still has deprecated APIs from years ago that people still decide to use which have player names instead of UUIDs. Vault uses UUIDs through OfflinePlayer objects, but this can cause unnecessary server freezes whilst it needs to request data of a player from Mojang's servers. This issue is significantly amplified with baltop operations, for example.
Non-player accounts	🟢	🟠	Vault's bank accounts require an owner, which is not suitable for all implementations. Treasury facilitates non-player accounts which are very similar to Vault's ban kaccounts although do not require owners or members, and have a unique per-member bank permissions list, providing a greater degree of control for economy providers. Due to the limitations of Vault's bank account implementation, it does not seem to have gathered the usage it should have. We believe that the changes we've made make it suitable for more plugins to use.
Multi-currency	🟢	🔴	Vault does not offer any multi-currency support whatsoever.
Code quality	🟢	🟡	See for yourself.
Multi-world	🟡	🟡	Vault makes it optional to use their multi-world methods, which in essence, is self-defeating for the feature. Although Treasury does not have direct multi-world methods, it does make it easy for individual currencies to operate in a per-world manner, effectively achieving multi-world support without the burden of bloating the rest of the API with it. Currencies can be specified to operate primarily in certain worlds, which provides a multi-world functionality. Such economies are only used by a handful of servers relatively speaking as they are difficult to manage in the first place.
Well-designed EconomyResponse	🟢	🟠	Treasury has opted to build upon Vault's EconomyResponse by making it a generic class instead, significantly upgrading its capability. It also supplies better communication potential through the economy API by supplying a variety of reasons why a transaction was unsuccessful, other than a 'yes or no' result. Oh, and you don't have to use the 'success' or 'fail' as a 'yes' or 'no'.. for some reason Vault does that.. :)
Transaction history	🟢	🔴	Vault does not offer this functionality.
Transaction events	🟢	🔴	Vault does not offer this functionality.