I will design out loud here in the Keykos context which is familiar to me. I will translate later if necessary.
Mark Miller recently pointed out that this makes sense only for fungible capabilities to exclusive resources.
If I offer some service then I, or some close colleague, will be the only one that generates promises for future service. The task is to arrange that I am unable to distinguish those promises as fulfillment is demanded. It seems clear that for non fungible services I will necessarily know which service is being claimed. I can think of no exceptions.
If that service is bandwidth on a communications fiber then such a promise will most likely be parameterized at least by duration, start-time and bandwidth. To simplify we assume that the future is permanently divided into one hour slots.
A mutually trusted party, the deliverator, can take delivery of promises for the entire bandwidth for some fixed future time slot. (The deliverator is a profession in Neal Stephenson’s Snow Crash. We used the term in a project at Sun for a similar function.) This is transferred from the real server to the deliverator in the form of a capability T. The deliverator holds T closely and effectively subdivides this gross capability into new capabilities, that it can distinguish, for specific hunks of the bandwidth. It sells or otherwise disseminates these capabilities. Upon request the deliverator will explain, agglomerate or subdivide these capabilities. A promise is thus good for a hunk (of bandwidth) for a specific slot (of time). A promise holder can “unshare” the promise by invoking the deliverator to cancel the old promise in exchange for a new one to the same BW hunk. This effectively rescinds and transfers title.
When it is time for a holder of one of these capabilities to claim the service the holder invokes the capability which leads to deliverator logic that requests (using T) of the real server, a capability for some definite size hunk of service now. The real server has no way to know who wields this newly created capability but is honors the request because it trusts that the deliverator plays by the rules and will not over commit the server.
This scheme has the flavor of a wholesale-retail stratification. There are engineering tradeoffs to be made here concerning the size of these time slots. Note that potato futures come in standard sizes as well. The deliverator need know nothing of the service being delivered. Variations of the deliverator may make the promises real upon some agreed upon event rather than merely when some time arrives.
This scheme is more complex and provides more function than the Chaum cash scheme. That is good and bad. It could be simplified to make it closer to the Chaum scheme.
P.S. This scheme doesn’t feel as if it solves the same problem as the Chaum cash scheme. Something happened as it was transferred across domains. I think that I have a concept map fault.