I think the middleware thing can be done by setting up the “right team” for the asset, a middleware is pretty much a proxy and we already have those, perhaps a bit of extra functionality in the existing delay of proxies could be useful(e.g. proxy accounts with dynamic delay), ideally an improved Proxy Pallet On Steriods could provide a more robust authorization framework with more options to configure. The rate limiting could be done this way and would be better as filtering is done on the receiving side, malicious users that already have root control of a chain can bypass the usage of a pallet like orml-tokens.
As a bit of a related note, I plan to do something like this with Virto, we won’t be the reserve of any token, we plan to use Statemint as the reserve for the tokens of our commercial communities and when the chain comes live(likely wait for parathreads) we bring tokens over. Something special about the setup is that after minting the total supply we made the owner and issuer an account with no private key, perhaps in the future with could gain ownership back with a referendum adding a proxy to that account using utility::dispatch_as but in the meantime it serves as guarantee that supply cannot be inflated. For the admin and freezer we setup a pure proxy that could later be controlled by the parachain and/or a special origin in the collectives parachain.
{
owner: 1VirtoSwapCash111111111111111111111111111111BFT <- no private key
issuer: 1VirtoSwapCash111111111111111111111111111111BFT
admin: 14duqNVtQ9SWGe1kahf8tkXxu5npaGrZ9numtftgNvqowCTd <-pure proxy
freezer: 14duqNVtQ9SWGe1kahf8tkXxu5npaGrZ9numtftgNvqowCTd
supply: 31,415,926,535,897,932
deposit: 100,000,000,000
minBalance: 1,000,000
isSufficient: false
accounts: 4
sufficients: 0
approvals: 0
isFrozen: false
}