Home
WowoK Protocol is an AI-oriented web3 collaboration protocol, empowering you to create, collaborate, and transact on your own terms. The WowoK protocol empowers the innovation of super-individuals and creates infinite demand and supply by forming real data and trajectories on the chain. It offers entities lego-like combinatorial collaboration capabilities, supporting a variety of custom transactional and business models, based on the high throughput and low-cost advantages of the Sui blockchain.
*Entity: It could represent the addresses of a super individual or an AI.
WowoK Protocol supports innovation, new business models and services. A series of creations can be undertaken:
- Personalized demand expressions and conditional incentives (Demand & Reward).
- One-click supply publishing, customizing immutable commitment: service progress and transaction terms (Service)
- Realizing transactions at all expected points by verifying existing and future data on the chain(Guard).
- More importantly, it allows for combination and innovation based on all services provided.
WowoK Protocol empowers super individuals to achieve their desires: collaboration between super individuals and AI.
- Data on open chain databases can be defined by super individuals. This data can then be referenced cross-organizationally, and resources of collaborative entities can be shared, ultimately reducing collaboration friction (Repository).
- Creating service progress that meet consumer market needs, controlling collaboration pace and quality, achieving sustainable supply satisfaction (Machine).
- WowoK Protocol targets AI-tagged data that AI can efficiently recognize, enabling efficient matching of personalized demands.
- Private ownership: Data ownership and privacy protection are essential requirements in the digital age. In the Wowok Protocol, data is authentic and owned by entities.
- Shared ownership: Permission Creator manages the granular permissions of entities (address) and objects, enabling ownership management and managed collaboration (Permission).
- Privacy-preserving: Private data can be securely transmitted using address-level encryption, which provides peer-to-peer sharing capabilities. This method ensures that on-chain privacy is maintained, safeguarding sensitive information such as contact details and delivery addresses (Posting & Order info).
Object is the fundamental unit of the Sui blockchain, featuring:
- UID: Each object has a unique identifier (UID) that can be searched for on the blockchain as an address.
- Ownership: Address-owned objects are accessible only to their owners; immutable objects have no owner and are usable but not mutable, transferable, or deletable by anyone; shared objects are accessible to all, with ownership governed by protocol rules.
The WowoK Protocol implements complex permission controls, with each object having a Permission table or Permissions. The WowoK Protocol provides the following infrastructure:
- Contract objects: Transaction models including service & order, demand, and reward objects primarily implement collaborative supply and demand expression and timely incentives, combining protocol objects flexibly into a complete service set.
- Progress objects: The WowoK Protocol uses state machines to clearly represent process diagrams, making collaboration processes visible and controllable. Machines are static state machines showing all possible states of a process; progress is the instance of machine, showing the actual states during the progress' execution.
- Common objects: In the WowoK Protocol, common objects like guards, permissions, repositories, and votes facilitate collaborative condition validation, permission control, data storage, and voting decisions.
These three types of infrastructure enable better combination and innovation, allowing both supply and demand parties to achieve effective transaction consensus and secure trading.
The WowoK Protocol provides AI and individuals with data, scenarios, and interaction rules. AI generates new, authentic data in Web3 according to these rules and changes data through interactions. AI makes decisions beneficial to entities using computational power, achieving:
- More effective supply and demand publication and matchmaking, reaching transaction outcomes.
- Prediction and optimization: Based on existing supply and demand and its capabilities, AI can create more personalized or scaled supply and demand.
- Universal uniqueness: Blockchain addresses are globally unique, unrestricted by any platform or organization, unifying all resources and data.
- Identity and reputation: Addresses can be used to build decentralized identity systems, storing identity information, history, and achievements.
- Data ownership: Addresses are controlled by private keys, with the private key holder having ownership and operational rights over the address. Users can fully control their data and assets without relying on any third-party platform.
Demand represents a personalized expression of needs and an incentive. Demand is a transaction matchmaking model centered around needs, facilitated through AI-driven search.
| Attribute | Definition |
|---|---|
| Description | Introduction |
| Bounty | Token or any transferable asset as a reward for a satisfactory presenter; if no satisfactory presenter is picked, the Entity with permissions can reclaim the bounty after the deadline. Bounty can be increased but not decreased. |
| Deadline | Deadline for presenting the demand, can be extended but not shortened |
| Guard | Address that meets the guard conditions and submits a service |
| Presentation | Service presenter provides the service and the recommendation to the service |
A traveler has posted a Demand: Wish to experience the Great Migration in Africa, seeking a relaxed travel itinerary with accommodations close to nature and a guide who can provide knowledge about wildlife and the natural environment. Service presenter that fulfill this Demand is eligible for a reward of 100 USTD.
Voice a need to the world, and let AI connect with presenters:
The presenter's AI has identified the demand, and they have integrated resources on the chain to create a new service that matches the demand, presenting a transparent fulfillment progress to the traveler.
After the traveler receives the services from the presenters, the traveler reviews the transaction and the service progress, chooses a favorite service, and the picked presenter can then receive 100 USTD tokens.
Reward is an incentive offered for meeting certain conditions, representing the publisher's commitment to incentivize specific future actions.
At the same time, rewards can be sent as lucky money to any address or a specified address based on the proportion. Meeting a certain condition entitles one to a specified share.
| Attribute | Definition |
|---|---|
| Description | Introduction, eg. the reward's purpose |
| Bonus | Amount and portion of tokens, equal distribution or random distribution of tokens; any transferable asset |
| Deadline | Deadline for claiming rewards can be extended but not shortened. After the deadline has passed, the entity with permissions may reclaim any remaining rewards. |
| Guard | Eligible for claim if guard conditions are met, with corresponding claimable portion |
| Sponsor | Address for replenishing bonus |
| Promise* to the immutability of Guard. | True: The guard conditions are unchangeable False: The guard conditions can be modified |
Promise* indicates an irreversible commitment once set to true.
- Distribute a lucky money: Send rewards to ten friends who follow you.
- Issue management grand prize: Incentivize Permission admins who manage multiple Permissions.
- Claim airdrop: As an incentive for users to build on the WowoK protocol, any user who completes a transaction on the WowoK protocol can claim a reward. Entities who have already claimed five rewards are eligible to receive an additional reward.
| Case | Guard | Portion |
|---|---|---|
| Claim 1 portion for each completed transaction | Complete a transaction | 1 |
| Claim 2 portions for each completed transaction and creation of machine | Sense 1: Complete a transaction And Sense 2: Create a machine |
2 |
| Claim five rewards from the WowoK Protocol can earn an additional portion | Claim five rewards from the WowoK Protocol | 1 |
Services are tradeable supplies with the following features:
- Service presenters can define, publish, and manage services flexibly, including details like service descriptions, product lists (with prices and stock), payees, withdrawal and refund rules, breach reward and custom interactive endpoints.
- They offer engaging transaction models and consensus preferred by market participants, such as financial and procedural agreements, and incorporate automated systems to customize service processes for smooth and transparent collaboration.
| Attribute | Definition |
|---|---|
| Token | All items within the service will only accept this token |
| Payee | Payee for the order |
| Description | Introduction |
| Item detail | Item name, price and stock of items for sale |
| Withdraw guard | Payee's withdrawal agreement, allowing for percentage-based withdrawals under certain guard conditions |
| Refund guard | Payer's refund agreement, specifying the percentage to be refunded based on guard conditions |
| Breach reward | Compensating buyers for non-performance or under certain conditions |
| Endpoint | Customizable interactive interface |
| Repository | Storage of service-related data |
| Machine | Consensus on service progress |
| Buy guard | Service purchase accessible only to users meeting buyer's guard conditions |
| Required information | Buyer information, such as contact details and shipping address, will be encrypted |
| Allow ordering | A commitment to buyers regarding the immutability of machines, withdrawal, and refund guards, token. Services can also be temporarily suspended or restarted based on service conditions |
| Clone service | Duplicating a service and being able to modify transaction token and consensus |
Order represents a paid transaction. Once a buyer successfully pays for a service, an Order is generated, during which both parties engage in a consensus-based process for refunds and withdrawals. Protecting buyer privacy: When storing additional information required from buyers, using encryption methods to safeguard user privacy.
| Attribute | Definition |
|---|---|
| Detail | Item name, price, quantity, to pay |
| Required info | Request buyer information |
| Discount | Discount used at the time of payment (Maximum discount is selected by default) |
| Progress | Service progress of the order |
| Payer | Payer's address for the order |
| Payed | Amount paid by the payer |
| Withdraw guard* | Payee's withdrawal agreement, allowing for percentage-based withdrawals under certain guard conditions |
| Refund guard* | Payer's refund agreement, specifying the percentage to be refunded based on guard conditions |
| Breach Reward | Compensating buyers for non-performance or under certain conditions |
*Withdraw guard & Refund guard: If one party withdraws a specified percentage of the funds, the other party can claim the remaining percentage. For example, if the Order Payer takes 80% of the refund, the Payee can retrieve the remaining 20% of the funds.
Service admin (defined by Service Permission) can set the discount for service(s). After the discount is launched, it becomes an asset for entites that cannot be tampered with.
| Attribute | Definition |
|---|---|
| Name | Discount name |
| Discount type | - Percentage discount - Fixed discount |
| Minimum amount | A discount will be valid if the purchase price is greater than or equal to the minimum amount required |
| Period | Valid during the start and end times |
| Service | For services or a service |
- Send to Existing buyers: Service administrators (Defined by Service Permission ) can send discounts to eligible buyers by setting guard, such as offering a 20% discount to buyers with multiple service engagements.）
- Reward for Future buyers: Discount can be a bonus transferable asset, claimable as a reward upon meeting certain conditions. Buyers can earn discounts of varying degrees by completing different levels of guard tasks:
| Condition | Guard | Discount percentage |
|---|---|---|
| Complete 1 task | Sense 1: Invite a new address to use the service Or Sense 2: Share the service with two addresses |
90% discount |
| Complete 2 tasks | Sense 1: Invite a new address to use the service And Sense 2: Share the service with two addresses |
80% discount |
- Businesses can customize transaction modes and rules, breaking free from the constraints of web2 platform rules. For example:
-
Setting custom transaction modes.
- Refund guard: Buyer get different refund ratios based on the refund time.
- Withdraw guard: Service provider can withdraw funds when the progress node's status is Transaction successful.
-
Reference objects on the chain, leveraging existing and comprehensive repositories, guards, and machines on the chain to create super high-quality services.
-
Defining own service machines, creating a new service by combining multiple suppliers.
Agent combines services that meet the traveler's needs into a new service:
- Buyers can witness the complete set of entitlements and service progress, including conditions for refunds and compensation. Service Buyers can view the full terms of service, payment agreements, and service progress:
- Users' service behaviors can be trained into their own consumption habits AI. With user consent and privacy protection, the blockchain can match the most satisfactory and needed services.
Machine represents a boundaryless collaboration that defines core data, sets its own consensus, and establishes collaborative patterns. Different entities, based on an unbreakable consensus, can cross organizational boundaries to achieve collaboration around service.
Within Machine, collaboration data can be aggregated and analyzed to identify issues in the collaborative process, forming authentic data and enhancing collaboration efficiency.
Machine connects to trusted tools, consensus, shared repository, and completes progress. It represents a state diagram, consensus repository, and permission for machine management.
A Machine State Diagram in the WowoK Protocol is a service progress diagram that includes operators and nodes.
Operators: These are entities that execute operations and can be either order payer (buyer) or collaborators involved in completing a service. There are two types of operators:
- Permission indexes: These are entity addresses with specific Permission Indexes assigned by Permission.
- Progress Operators: The Machine builder inputs a progress operator name, which can be a protocol-provided name like "Order payer" or a custom name like "Delivery person", different entities at different progress stages. Assuming the progress operator is Order payer, the progress is initiated after the buyer makes the payment.
Nodes: Nodes represent states that can be reached by satisfying guard conditions. A pair of adjacent nodes is called a node pair, which can have one or more operators. By default, if one operator meets the guard condition, the progress can move to the next node. A threshold can be set for collaborative tasks requiring multiple operators.
Weight & Threshold: The threshold is a total value, defaulting to 100. When the sum of the weights reaches the threshold, the next node is triggered. For example:
- If two operators have weights of 50 each, both must satisfy the guard to proceed.
- If three operators have weights of 50 each, any two can satisfy the guard to proceed.
Guard: The conditions that an operator must meet to complete an operation.
Machine State:
- Pause running a progress: Cannot run a progress.
- Allow running a progress: Can run a progress. Once a progress is initiated, it indicates that a consensus has been reached, and the Machine cannot be modified. To edit the Machine, a clone can be made and then edited.
Endpoint: the Machine Permission Admin can customize an interface to provide a better user experience. Users can perform operations at corresponding consoles based on their current node.
-
Repository: Machines are assigned a repository where all progress data are saved. The Repository is used to define data and create new collaborative models.
-
Permission: Adding Permission to the machine allows for the separation of process operations and entity management.
Progress is an instance of running machine, including the original machine, parent progress, repository, current and historical nodes, and operators.
| Attribute | Definition |
|---|---|
| Current node | Current state |
| Current operator | Address that completes the current operation |
| Historical node | Historical progress state |
| Historical operator | Historical operation and operator |
| Original machine | Complete progress, predicte workflow trajectory |
| Parent progress | Independent progress of collaborators |
| Repository | Store the data generated by the collaboration entity during the runtime of Progress |
Entities can directly view the progress and state, providing a reference for the next collaborative combination. Collaborators receive operation notifications and can perform operations on the corresponding page, accumulating their completed progress as a form of capability proof.
Progress Initiator, two ways to start a progress:
- Based on the allocation of Machine Permission, the entity with the granted permissions can initiate progress, set a progress operator, and manage repositories, among other capabilities.
- Service Progress Initiation: After a certain address pays for a service and forms an order, it automatically becomes the order payer for the progress and initiates the progress.
Parent progress: Each business has its own progress, and collaboration between businesses can be achieved through progress connections. For example, in a product transaction progress, it is a parent progress of the shipping company's progress.
Repository: The shared database for collaborators. All service or progress collaboration consensus can be stored, managed, and written in the progress repository.
Guard is an executable on-chain conditional consensus; it passes validation when its conditions are met, and fails if they are not. Once launched, a Guard becomes an immutable object, and all data generated by objects can be referenced by a Guard. By referencing a Guard address, it can be used in scenarios requiring conditional validation, such as claiming rewards, refund conditions, voting eligibility. A Guard is a set of senses with the following attributes:
| Attribute | Definition |
|---|---|
| Description | Introduction |
| Sense | Senses determine conclusions of true or false, and can be combined using 'and' or 'or' - Combining senses with 'and' requires all conditions to be met for validation - Combining senses with 'or' allows validation if any condition is met |
| Constant | Frequently used data or future data source |
-
Reward Guard: If someone sets me (0x538d06) to admin of Hogwarts Permission (0x64f34d), they can claim a reward of 50 USTD.
- Guard: Verify whether the address 0x538d06 is an Admin of 0x64f34d [Hogwarts Permission].
-
Refund Condition: Return within 7 days for a full refund; return within 15 days for an 80% refund
-
Sense 1: Order Time of 0x64f34d [Trip Service]<7 days, 100% refund
Or
-
Sense 2: Order Time of 0x64f34d [Trip Service]<15 days, 80% refund
-
-
The guard can reference future data, such as orders generated by services in the future or progress initiated by machines in the future.
Permission is the allocation of operational rights for objects, with each object creation requiring a specified permission. A Permission can manage multiple objects and facilitate fine-grained access control by assigning permission indexes to entity addresses. Simultaneously, it also allows for one-stop management of personnel permissions.
| Attribute | Definition |
|---|---|
| Description | Introduction |
| Builder | Creator and admin for Permission : - Creator: Transfer the authority of the Permission object; manages admins - Admin: Distribute permissions |
| Permission table | Manage permission indexes for entity addresses |
The diagram below shows the Permission table of the Repository, where this Permission can manage multiple Repositories.
- Granular Responsibility: Trip agency assigns different levels of permissions to employees for different objects.
- Agency Staff (0x538d06):
- Machine: Set description
- Repository: Modify the description of an existing policy
- Agency Director (0x5b3e4d):
- Machine: Set description, Add consensus repository, Add node
- Repository: Add the policy to the repository
- Service: Create discount coupons
- Agency Staff (0x538d06):
- Transparent Abilities: By managing Permission, entities with specific and authentic abilities are transparently recorded on the blockchain.By showcasing the real capabilities of an entity through permission indexes, it can further translate into new demands. For instance, if an entity (0x5b3e4d) holds the permission admin for multiple objects, it indicates that this entity possesses managerial abilities. AI can search for these real management experiences recorded on the blockchain, including the frequency and outcomes of operations. If someone's business requires managerial personnel, they can enlist the help of this entity (0x5b3e4d).
- Permission management is dynamic, allowing seamless switching at the organizational level. This means that team or individual permission indexes can be quickly adjusted based on business needs without altering the underlying business. Permission enables the separation of entity management (Permission) and business (Object), making both the business and permission structures more scalable and maintainable.
Vote offers better decisions through public voting. It can be cast on matters such as proposals and disputes, or on objects.
| Attribute | Definition |
|---|---|
| Description | Introduction |
| Option | Voting options, can vote for a specific object |
| Guard | Eligible for voting if guard conditions are met, with corresponding voting weight |
| Deadline | Voting deadline |
| Allow voting | True: Voting is allowed, and options are not changeable False: Voting is not allowed, and options can be changed |
| Promise* to the immutability of deadline | True: The deadline cannot be modified False: The deadline can be extended but not shortened |
| Promise* to the immutability of Guard | True: The guard conditions are unchangeable False: The guard conditions can be modified |
Promise* indicates an irreversible commitment once set to true.
- The scale and outcome of the vote can serve as a guard condition, for example, the first-place vote in a poll could receive a 'most popular' guarantee and a 500 USDT reward.
- Dispute Resolution: Dispute resolution community initiates a vote to resolve on-chain transaction disputes. Influential voters (multiple successful votes) have more voting weight to improve accuracy.
- A more advanced model: assigning different voting weights to different entities based on their identity when evaluating and deciding whether to approve projects that may have a significant impact on the environment
| Case | Guard | Weight |
|---|---|---|
| Voters with an international-level environmental guarantee have the highest voting weight | Verify if the voter has an international-level environmental guarantee | 6 |
| Voters with a social-level environmental guarantee have a moderate voting weight | Verify if the voter has a social-level environmental guarantee | 3 |
| Regular voters | Verify if the voter has an environmental guarantee | 1 |
Repository serves as a consensus and shared data library, enabling the definition, management, and collaboration on data.
Policy Name is the title for data indexing, and enables the implementation of data consensus. In different modes, only entity addresses with the Permission index are allowed to submit data for the designated Policy Name.
Entities on the blockchain can reference repositories with established consensus, facilitating infinite combinations of data.
| Attribute | Definition |
|---|---|
| Description | Introduction |
| Value type | Bool, string, number... |
| Policy | Data rules: Who can write, data name, data type |
| Policy mode | -Free mode: Allows entry of data other than policy. Used for informal, non-consensus situations. -Strict mode: Prohibits entry of data beyond policy. Used in formal, fully consensus contexts. |
| Data | Stored data |
| Repository type | 1. General Repository: Created by entity 2. Wowok Grantee Repository: Created by the Wowok protocol |
-
If a trip agent combines airlines, hotels, and guides into a new trip progress, each collaborating party will agree on the service's repository. For example, the trip agent and other collaborators (airlines, hotels, etc.) reach an agreement on the policy "Order number", collaborators joining the progress write data according to the policy "Order number".
The diagram illustrates the contents included in a Policy:
The permission index of the Policy is managed by Permission:
- Data from the repository can be referenced in different objects such as Guard and Machine . For example, the progress node can be determined by whether the data in the repository is complete. For instance, the progress can only move to the next node when the courier fills out the tracking number in the merchant's repository.
- Grantor & Grantee: An entity can apply to become a grantor to the Wowok protocol. The grantor acts as a trust transfer tool and can authenticate other entities as grantees. For example, if an entity address manages a significant volume of Permission business transactions, the grantor can confer upon this entity the title of 'Best admin.' This grant will be recorded in the Wowok grantee repository.
The object Wowok Grantor is owned by Wowok Protocol. Any entity can apply to become a grantor to the Wowok protocol. The grantor acts as a trust transfer tool and can authenticate other entities as grantees. WowoK protocol generates a grantee repository for authorized grantors, which is used to manage and store grantee information.
You can send public messages or encrypted messages to specified addresses.