How ArcBlock Uses NFTs to Represent Application Resources
Open an application, connect your DID Space, select its NFT in your wallet, and continue to the storage service. ArcBlock already provides this workflow. The first time someone sees it, a reasonable question follows: how does choosing a card in a wallet tell an application which storage space to connect to?
That small interaction shows a practical use of NFTs in ArcBlock. We represent rights associated with a resource as objects that can be held and verified. The service providing the resource then evaluates those rights when it handles a request. Storage spaces, domains, software licenses, application instances, and access eligibility can all participate in this model. Each keeps its own meaning and rules, while identity, rights, and current ownership are connected in a consistent way.
Storage is a useful place to start. Once that connection makes sense, the domain and application examples are much easier to follow.
What the card in the wallet points to
The DID Space connection components offer a concrete example. A user can select a space through DID Wallet. After connection, the application receives information including the space's name, DID, and gateway address. It can also start a connection from a particular gateway address, narrowing the wallet's selection to the relevant NFT.
The card has information for display and information the system can verify. It connects a holder with a resource relationship involving a particular space. Files remain in the storage service, where reads and writes are processed. The card gives the application a way to identify the resource and enter the relevant identity and permission checks.
This separation matters to the design. Storage capacity is managed by the service. Permission to use that space involves evidence about identity and rights. Expressing these separately means an application does not have to treat a user account and every resource associated with it as one inseparable object.
A person can have several spaces. An application can let that person choose which one to connect. Selecting a space does not automatically give the application permission to access every file in it. Operations remain subject to the authorization the service recognizes.
Connecting a right to a resource
In this ArcBlock design, a DID identifies a participant or resource. A Verifiable Credential, or VC, carries an issuer's claim about rights. An NFT connects the claim with a trackable ownership state.
DID stands for decentralized identifier. A user can have one, as can a storage space or an application instance. It answers an identification question: which participant, service, or resource are we talking about? An identifier does not grant permission on its own. The W3C DID standard also does not require every DID to use a blockchain.[1]
A VC is a claim with a verifiable proof. Here, a resource controller can issue a claim describing rights associated with a resource. The claim might concern a software license, eligibility for an application role, or storage use with capacity and duration limits. A verifier can check the claim's origin and integrity. The service applies its own rules to decide whether to accept it.[2]
An NFT provides ownership and state records for an object that needs to be identified individually. When its rights are transferable, the system can check who currently controls it, rather than relying on whoever still has a copy of an earlier claim.
The responsibilities fit together like this:
| Part | Question it answers |
|---|---|
| Participant and resource DIDs | Who and which resource are involved? |
| VC supplied by an issuer | What rights are claimed, and under what conditions? |
| Current NFT state | Who holds the object now, and what relevant state changes have occurred? |
| Resource service | Does this request meet the conditions, and which operation should run? |
A software license can specify how many instances may run. A storage entitlement can specify capacity and a validity period. A Passport can represent eligibility a service recognizes. The objects share an approach to representation while keeping their own business rules.
This is why the word “ownership” needs an object after it. Holding the right to administer an instance is different from holding a license to run a piece of software. The distinction should be visible to the user and enforceable by the service.
The service makes the connection operational
Writing “access to a server” in an NFT description does not change a server's behavior. A resource manager needs to understand the claim and connect the result of verification to an actual operation.
ArcBlock includes that step in its resource management design. When a user requests an operation, the service verifies the requester, checks the relevant NFT's ownership state, and determines whether the rights cover the request. Once the conditions are satisfied, it performs the permitted action, such as starting an application or connecting storage.
It helps to picture three cooperating layers. On-chain objects and records provide ownership and relevant state information. A management layer interprets that information alongside service policy. The underlying resource runs programs, stores data, or provides a network service. Checks and execution happen where needed; this does not require a blockchain transaction for every file read.
The service's part is essential. A valid signature means the claim passes the corresponding cryptographic check. Whether an operation should run also depends on whether the issuer is accepted, the requester may use the claim, and the service conditions are met. W3C makes the same boundary explicit: the VC data model needs an accompanying authorization framework for resource access control.[2]
That is why NFTs, credentials, and resource management belong in the same explanation. Together, they participate in a usable service relationship. Issuing an object is only part of explaining how someone can use it.
From a storage space to domains and applications
Domains provide another tangible example. DID Names domain hosting supports domains registered with other registrars. After the relevant hosting and subscription steps, the user receives a DID Names NFT in the wallet and can use the domain on the Blocklet platform.
The NFT represents the domain use and management relationship recognized by the service. The original registrar still has its responsibilities in the domain registration system, and DNS still operates under its rules. An existing domain can participate in the same wallet and resource verification experience without rebuilding the internet's domain system.
Presenting an NFT or Passport to an application illustrates a different relationship. The application asks for evidence of eligibility. The wallet lets the user choose and present a qualifying object. Presentation supplies proof; it does not send the NFT to the application. After verification, the application provides access according to the relevant role or permission.
Software licenses and application instances have their own rights objects, too. A license specifies permitted use of software. An instance's control relationship identifies who may administer that particular running application. Separating them allows a system to distinguish permission to use software from permission to manage one of its deployments.
These resources can be managed independently or used together by an application. An application that needs compute, storage, and a domain can combine separately verified resource rights. A common representation gives applications and providers a shared way to identify and verify those rights. The resulting service still respects each resource's conditions.
What changes when a resource right is transferred
Where a right is transferable, transferring its NFT can carry the handover. The new holder can use the corresponding resource after verification. The previous holder can no longer rely solely on the transferred object as proof of continuing ownership of that right.
The important words are “transferable” and “corresponding.” Eligibility tied to a person, a limited-duration entitlement, and an application's administrative control can have different transfer rules. Identity, roles, resource ownership, and usage rights need distinct treatment. Appearing in the same wallet does not make them interchangeable.
The service also has to apply a change in rights to access. New requests should be evaluated against the new ownership state. Existing sessions are handled under the service's session and permission rules. The transfer record and resource-side execution work together to make a handover effective.
This also defines where the model is useful. A simple application serving only its internal accounts can manage permissions in its own database. An independent rights object becomes particularly useful when a resource needs to be recognized across applications, presented by its user, or handed to another holder under explicit rules. A blockchain record does not operate the service or guarantee its availability.
Back to the resource
In our 2021 discussion of NFTs, DIDs, and VCs, we already connected these ideas to underlying services. DID Space connections, DID Names usage, and Passport presentation put those relationships into product workflows people can use.
Return to the opening interaction. A person selects a space in a wallet. The application identifies the relevant resource and proceeds through verification and connection. The person does not need to reconstruct the architecture in their head. They should still be able to understand what they selected, what they permitted, and why the service accepted the request.
That is the purpose of using NFTs for application resources in ArcBlock: give resource rights an identifiable object, make the object verifiable, and make verification part of actual service execution. The wallet card becomes an entry point to using a resource, with each part of the system doing its own job.
References