Applications for our incentivized testnet are now open, you can apply here. The application deadline is March 20th, 2021.
Our current plan is to release mainnet in the summer of 2021. The timing for token sale has not been determined.
In programming, we often want to restrict access and only give certain users or programs the authority to perform certain tasks. Object capabilities (ocaps) and access control lists (ACLs) are two ways of handling access control.
Identity-based access control such as ACLs make sense at the boundary of humans to computers, such as when a new employee is hired and given a certain set of permissions which will rarely change. However, in order to bring the world economy online through smart contracts, we need the ability to rapidly derive, compose, and transfer rights among a mix of computer agents and humans. ACLs have difficulty handling this level of complexity.
We often use the example of valet parking to distinguish between ACLs and object capabilities:
Imagine you are checking into a hotel and drive up to the valet parking. You hand them your key, and continue checking in. Later that night, you want the car to go out for dinner. The original valet has gone off duty, but there’s no trouble, since he has given the key to the new valet. In this example, the key represents an object-capability.
But what if your car used an ACL instead? You check into the hotel, but this time, you take down the name of the valet and add it to your car’s list of people who are allowed to drive it. However, when the new valet goes on duty, the old valet doesn’t have the permissions to edit the car’s access control list, so the new valet cannot retrieve the car.
Perhaps, anticipating this, you hand over your driver’s license to the valet when you check in. Then when the new valet comes on duty, the old valet can just transfer over the driver’s license, so that problem is solved. However, now the new valet can take your ID and steal your identity. Letting the valets act as you enables them to do anything you’re allowed to do.
In an ocap framework, rights are represented by computational objects. Holding the object (having a reference to it) is fully sufficient for being able to use it. Therefore, access can easily be limited to the least authority necessary.
Current smart contract platforms generally use identity-based access control, which has known limitations. Smart contract developers have found ways to work around the limitations of identity-based access control, but ultimately, these limitations are insurmountable when trying to create a fluid world economy. For instance, it is currently possible to write a simple smart contract to give someone the power to buy an asset (say, a stock) at a certain price over the next month. This is effectively a covered call option. However, the covered call option in Ethereum or another smart contract platform can’t participate in the larger market — the person who has access can’t turn around and sell the access to a third-party. The contract creator can write a transfer function, but then the contract creator must be able to anticipate all of the needs at contract creation and writing smart contract functions is expensive and error-prone. By contrast, with ocaps, transferring the right to a contract is trivial, and access to an opportunity becomes a bearer instrument by default, allowing something like a covered call option position to participate fully with the rest of the ecosystem, such as being sold at auction, on exchanges, etc.
document in the browser, or
fs (the file system) in Node.js. These scope lookups can be intercepted, analogous to how hardware provides an operating system designer the ability to intercept access to the hardware and external world.
 There are four exceptions to the clear separation between pure computation and effects: Date.now(), Math.random(), timezones, and current locale for purposes of internationalization. SES repairs these by other means.