# Overview ## What is Wundaflow? Wundaflow is a highly-available workflow engine designed specifically for applications that need to interact with the blockchain, or smart contracts that need to interact with the real world. On a basic conceptual level, you can think of Wundaflow as IFTTT for crypto. However it's so much more than that! As well as providing programmable event workflows and super-powers to your smart contracts, we also inject resilience and scalability to your web2 applications while allowing to you to keep full control of any components you want to. High-performing engineering teams already know the power that workflows bring to their codebase, Wundaflow extends that to web3. ## How does it work? We expose a powerful UI to author & schedule workflows as well as simple API endpoints to start, pause, resume and monitor your workflow executions; all while providing a real-time communication channel back to your web2 application via webhooks (HTTP POST requests). At the heart of Wundaflow sits our core workflow engine that can recover from process crashes, network outages, overloaded 3rd party services and many other typical failure scenarios; meaning your app will never miss an event again. {% hint style="info" %} Using our AWS, GCP or Azure server-less function connectors or by utilizing our embeddable JavaScript native task, you can build entire applications that are 100% automated and require no self-hosting capability at all. {% endhint %} ##
{% content-ref url="/pages/fLXTrJnpPINCrrfre2zJ" %} [Typical use-cases](/typical-use-cases) {% endcontent-ref %} # Roadmap {% hint style="danger" %} This page should be considered as **work in progress**. The information presented here is yet to be finalized. {% endhint %} ### Wave One: Pre-launch Unlike many projects in the crypto space, we're not asking you to fund a whitepaper filled with empty promises. Our token pre-sale does not start until our MVP is up and running; our first phase will be delivered 100% through sweat equity of the founding team.
Milestone 1: Strategy & MVP in progress * Ideation & strategy * Create founding team * Finalize branding * Commence build of MVP\ \- API design (OpenAPI spec)\ \- Architect infrastructure (Terraform)\ \- CI/CD pipelines\ \- Write initial documentation\ \- EVM event capture and streaming * Develop game smart contract * Launch Wundaflow MVP for internal use
Milestone 2: Site launch & game promotion * Build and launch initial website * Build and launch public docs * Complete audits of game contracts * Open whitelist for NFT game along with website launch * Commence NFT game marketing campaigns
Milestone 3: Token pre-sale * Finalize tokenomics * Open community channels (discord, reddit, etc) * Develop and audit $WUNDA token contract * Develop and audit $WUNDX token contract * Open whitelist * Commence token marketing campaign * Launch pre-sale
Milestone 4: NFT game launch * Complete Wundaflow MVP to include all functionality required for NFT collectible game launch * Launch NFT game
Milestone 5: Token launch * Token launch * Open reward pool * Token listings on CoinGecko & CoinMarketCap * Token listing on Uniswap (DEX) * Commence CEX listing drive (targets TBC) * Begin influencer marketing drive
### Wave Two: Post-launch After our token sale is complete, funds will be available to rapidly iterate on our core product and execute our business goals. Primarily this will mean a round of intensive hiring on the engineering team followed by fleshing out the Wundaflow feature-set to fulfil all launch requirements.
Milestone 6: Corp & team expansion * Add key members of team:\ \- 2x solidity developer\ \- 3x back-end developer\ \- 2x front-end developer\ \- 2x devops\ \- engineering manager\ \- designer\ \- community manager\ \- 2x community moderator\ \- 2x marketing\ \- partnerships / key account manager * Incorporation in crypto & gaming friendly jurisdiction * Bring triplicate nodes online for Bitcoin, Ethereum, Base, BNB Chain and Polygon * Begin Bitcoin L2 testing
Milestone 7: Development roadmap * Finalize short & mid-term feature roadmap * Define SDLC * Ramp up feature output * Website/branding redesign * Open lottery pool * Developer zone\ \- web-based playground\ \- API SDKs for popular languages\ \- Barebones starter project on github * Begin alpha testing
Milestone 8: Partner acquisition & beta * Begin beta with launch partners * Investigate FIAT on-ramp
Milestone 9: Wundaflow SaaS public launch * Add support for Avalanche, XRP Ledger, Stellar, EOSIO and Cardano * Extensive PR campaign kick-off * Open public signups * Wundaverse landing zone launch to coincide
Milestone 10: Smart contract marketplace Many projects require 'cookie-cutter' contracts - that is, functionality that's not specific to their project but needs reinventing and redeploying again and again. The Wundaflow contract marketplace will allow deployment of secure, audited contracts along with corresponding workflow examples to interact with those contracts.\ \ For example: * ERC721 (NFT) contracts designed specifically for Wundaflow deployment to handle whitelists, reveals, randomness and more. * Yield farming contracts such as staking pools.
Milestone 11: Fulfil development roadmap As part of our alpha/beta testing stages, as well as community feedback, we will have a comprehensive long-term roadmap that will guide the next 12-24 months of engineering effort.
Milestone 12: Compliance & accreditation SOC2 Type I\ SOC2 Type II\ ISO 27001
### Wave Three: Future 2026 and beyond.
Milestone X: Wundaverse expansion The Wundaverse will be a key part of our ongoing strategy, showcasing innovation facilitated by Wundaflow. We expect future games to incorporate metaverse, AR and VR. SDKs for Unity, Unreal Engine, CryEngine, Gamemaker: Studio and more will be developed in order to foster adoption from web2 game developers.
Milestone Y: Launch of WundaChain L2 blockchain, owned and operated by Wundalab. WundaChain will enable gas-less, near-instant transactions and usher in a new era of growth for the project ecosystem. Participation in the network will require staking of $WUNDA with an innovative decay algorithm.
Milestone Z: DAO As a final step in the documented roadmap, we aim to seek community involvement for project direction in the form of the **WunDAO:** a unique governance model enabling community voice with ratification by council primarily led by the core team. Additionally, we plan to build a DAO treasury fund to invest in early stage GameFi and DeFi projects.
# Typical use-cases Workflows lend themselves to almost every facet of engineering, but especially so with DeFI where there is always some degree of one-way or two-way sync required. We cover some loose examples of where workflows make sense below, but remember this is just the tip of the iceberg! {% hint style="info" %} Do you have a project or dApp where you think Wundaflow could help? please reach out to us to set up an exploratory call. {% endhint %} **You can build entire apps on Wundaflow or simply use it to orchestrate blockchain events using your own serverless functions under your own self-managed cloud account.**
GameFi GameFi is the intersection of Gaming and Finance and covers a wide spectrum including play-to-earn and bet-to-earn games. Automation with robust workflows is imperative to the success of many projects in this space as missed events, unreliable mechanics or poor UX can leave them dead in the water. Typical use-cases: * NFT games can use time-based triggers to execute workflows that start or end new rounds, decide winners or even inject randomness into battles.
* Once a user has initiated a game play with a smart contract transaction/method call, the game often needs to respond. Workflows can monitor contract addresses and, using logic triggers, complete any required tasks (such as calling server-less functions, fetching real-world data or sending notifications).
* Automatically generate a custodial wallet for each user and attach logic-based workflows based on interaction to/from that wallet address.
Gaming A fictional game - *Planet of Warcraft* - wants to enable custodial asset ownership and develop a trade marketplace outside of the core game. Each asset class in the game is minted as a unique ERC-721 NFT. For example, there is a Sword contract and an Axe contract. Each Sword or Axe NFT minted can have various traits, including materials, damage inflicted and power multipliers. The game is a MMORPG (massive(ly) multiplayer online role-playing game) and, as assets are custodial, they could be exchanged between players in a p2p manner entirely transparently to the game operators. They develop a series of workflows, including: * **notify-on-transfer**: using a logic trigger. this workflow watches for calls to the `transfer()` method on each asset contract and sends a webhook to their web2 back-end to update the local database.
* **generate-on-mint**: as assets can only be created by the game operator, this workflow is executed via API call. It calls a series of AWS Lambda server-less functions to create the asset images and store in S3, generate metadata and store on IPFS, call the asset contract `mint()` method (using a custodial wallet) then sends a webhook to their web2 back-end to update their local database.
* **modify-trait**: as assets can gain new/improved traits based on in-game actions, this workflow acts in a similar way to ***generate-on-mint*** by updating imagery and metadata for the given NFT using AWS Lambda functions. Enabling async guaranteed workflows for their blockchain interaction means that *Planet of Warcraft* can continue their low-latency gameplay while giving players true ownership of their assets - all with some simple outbound API calls and their existing webhook ingest pipeline. A huge win for their engineering team! Other example gaming use-cases: * Dynamic in-game elements: modify a characters appearance in-game based on how much Eth a player has in their wallet, how many reward tokens they've accumulated, or any other on or off-chain datasource.
* Autonomous NFTs (aNFT's): move an NFT between wallets entirely automatically as part of your game mechanics.
* ... and so much more.
NFT collectibles *Bored Monkey Kayak Club* - a purely fictional group - are releasing a new NFT collection, but they want to create a real-time interactive web portal as well as add some features that aren't possible entirely on-chain. They create the following workflows: 1. **notify-on-mint**: this workflow watches their ERC721 contract address on Ethereum and sends a webhook to their application whenever the `mint()` method is called. The webhook updates their local SQL database and keeps their displayed stats fresh.
2. **upgrade-on-triple**: this workflow is triggered as a sub-flow from ***notify-on-mint***. If the wallet address that mint's an NFT already owns two other NFT's from the collection, they all get upgraded. To achieve this, the workflow calls an AWS Lambda function that re-generates the NFT image using the newly added trait, uploads new metadata to IPFS and then calls the `update()` method on the smart contract. It then sends a webhook to the web2 app to update the users stats.
Dynamic digital assets Digital assets (NFTs, SBTs. etc) will be fundamental to the next crypto bull run, with new technologies and fresh takes on old technologies being paramount to project success. Adding an element of dynamism to your game assets or digital passes cannot be simpler using Wundaflow. Some examples include: * Modify NFT art traits or layers based on real-world data (e.g., change the background if the BTCUSD price hits a given threshold).
* Create a revenue stream by selling advertising takeovers of your digital pass creative. Use time-based triggers to add and remove the takeover on a set schedule.
* Support paid upgrades by adding a logic trigger on a deposit wallet address to monitor for inbound payments and automatically trigger an upgrade workflow.
Cross-chain payments While sending payments from one wallet to another on a given chain is trivial, cross-chain payments are still difficult. Using Wundaflow, a payments workflow could check price feeds using a web scraper task followed by performing an 'auto-swap' on a DEX (such as Uniswap) and then dispersing funds on the target chain. Alternatively, sending a recurring payment (like a salary or subscription) becomes trivial using a custodial deposit wallet and a long-running workflow with a perpetual loop using a `sleep()` call.
Trading bots While exchange specific trading bots can be reactionary and built entirely on trade feeds over a websocket, most advanced bots will use cross-exchange data as well as non crypto input. Using Wundaflow it's possible to: 1. Automate the flow of funds to various exchange accounts based on market conditions. 2. Execute trades on some exchanges using our exchange connectors. 3. Incorporate AI models (ChatGPT, Amazon Bedrock, Google Vertex, etc) into your decisions using a connector or serverless function. 4. Use a timed trigger to execute a workflow based on scraped data from a webpage. 5. Buy $DOGE whenever Elon tweets about Shiba Inu.
Futures Use time-based triggers to automate workflows on futures expiry, or maintain real-time price feeds using web scraper data for perpetual futures.
Stablecoins Using custom workflows and serveless functions, build a completely automated decentralized or algorithmic stablecoin. Peg to another currency using web scraper price feeds or trigger burn/mint worflows to maintain the peg.
DAO / governance Deploy a live voting application on web2 that updates in real-time using a websocket stream of events from transactions to the voting contract using a logic trigger. Automatically disperse a DAO treasury fund or manage a portfolio using logic-based triggers and voting mechanics.
Money markets Use a timed trigger to update a contract with price feeds for dozens of cryptocurrencies from a web scraper deployed as an AWS Lambda function using headless Chrome. Calculate amortization, collateral and debt and trigger liquidation workflows and user notifications based on custom logic.
Asset management Manage LP position across DEX by automatically re-balancing positions using automated workflows on time-based triggers. Alternatively, execute trade strategies based on custom logic to ensure optimum execution time for maximum profit and reduced risk.
Yield farming Depositing assets in order to earn rewards is known as yield farming. A popular type of yield farming utilized by many crypto projects is staking but other types of yield farming exist such as liquidity mining and proof-of-stake participation.\ \ A staking pool can easily be deployed on Wundaflow using either a long-running workflow or time-based triggers. In both instances, the idea is to 'lock' deposits for a given period of time and then unlock at a given point in the future. While this could be hard-coded in the contract, doing so removes both flexibility and the option to re-use the deployed contract at a future date.
NFT-backed loans New financial instruments are being enabled by DeFi all the time. One popular product is loans leveraged using NFT's as collateral. Using Wundaflow, a workflow could be executed upon deposit of a given NFT that completes an appraisal of the asset value using web crawlers built as AWS Lambda functions. The borrower could then have a period of time to revoke the transaction before the loan is automatically approved. The borrower then has a further period of time to pay back the loan in order to have the NFT returned. A separate workflow can run on schedule (weekly, daily, hourly) to calculate interest and amend the balance.
Fiat on-ramps During token sales, users need to carry out multiple steps that are not always simple for those that are not tech-savvy. They may need to get their Fiat onto an exchange, buy some Eth, set up Metamask or Trust Wallet, transfer the Eth from the exchange to their new wallet address, and then finally they can complete a transaction. Using a typical PSP (payment service provider) you can simplify on boarding customers using your web2 application and trigger a workflow that automatically sends the tokens to the users address.
Sports prediction markets Blockchain-based sports betting is new and exciting space. Users can speculate on outcomes in various sporting events including soccer, basketball, motorsports and even drone racing. Time-based workflows can be triggered to immediately settle the results of sporting outcomes, disperse funds and close markets using external API calls, data collected from web scrapers or other methods.
SaaS credits Typically, a utility token is used to pay for a service, either via subscription or via one-off payments. In either scenario, a barrier to entry - especially with micro-payments - is often the high gas fees on those transactions, that may occur regularly. Using the Global KV Store and an on/off ramp smart contract, much of those high gas fees can be mitigated by converting crypto payments into service credits instead. A user sends funds to the smart contract address, which is converted into credits and the credit balance is then stored in the KV Store. This is accessible by both the workflows and your web2 app via API calls. As credits are consumed, the balance is updated. If the user wishes to withdraw credits then they can do so at any time, but while the credits are in use there are zero gas fees to contend with. Wundaflow itself uses this very method with our $WUNDA token.
Bridges / atomic swaps Bridging between chains and even between tokens on the same chain is still difficult to achieve for many projects in a secure but controlled way. Using Wundaflow however, you can utilize our guaranteed execution workflows to trigger your own serverless functions to ensure 100% control over the bridging rules and authorizations.
Tokenized RWA (real-world assets) Trigger on-chain actions from real-world events and facilitate trading of tokenized assets on primary and secondary markets by utilizing automated workflows. Tokenization is set to make huge strides during 2024 and 2025 as laws and related legal processes catch up with the fast-paced world of blockchain. Tokenized RWA's will start to become commonplace in real-estate and fractional ownership situations such as corporate shares, physical collectibles, music royalties, venture capital, patents, luxury goods and more.
Reward token automation Easily build reward token mechanics into existing utility tokens/ecosystems by implementing a cross-chain reward workflow triggered every time a wallet interacts with your existing contract. This is often very difficult to build into contracts that have already been deployed but using Wundaflow it becomes as simple as creating a watch trigger. No elongated 'claim' processes for your users and no extra support load this brings to your team; just instant airdrops.\ \ Our own $WUNDX rewards token is (obviously!) powered by Wundaflow.
Staking / liquidity pools Automate all aspects of liquidity pools and staking pools by creating logic-based triggers based on volume or time-based triggers for fixed=period pools.
# Glossary Key terms used across the Wundaflow platform. *** #### **Workflow** A programmatic sequence of steps triggered by an event and executed automatically by Wundaflow. Workflows can be paused, resumed, cancelled, and queried via API. *** #### **Task** An individual operation within a workflow. Tasks can be native JavaScript functions, external API calls, or serverless function invocations. *** #### **Trigger** A condition or event that starts a workflow execution. Triggers can be based on blockchain events, schedules, API calls, or other third-party system events. *** #### **Signal** A message sent into a running workflow to update its state or resume execution from a paused state. *** #### **Worker** An external component that polls for and executes tasks defined in a workflow. Can be used to integrate custom logic or handle domain-specific operations. *** #### **Webhook** A real-time HTTP POST message sent to your application to inform it of events in a workflow lifecycle or other system-level events. *** #### **Retry Policy** A configuration attached to tasks or workflows that defines how failed steps should be retried, including back-off strategy and limits. *** #### **KV Store** A key-value store either (1) scoped to a single workflow execution, used to persist lightweight data between tasks; or (2) scoped to global context, used to persist long-term data across all workflows. *** #### **Wallet** A blockchain wallet that can be generated, managed, and used to sign transactions as part of a workflow. Wundaflow can generate wallet addresses programmatically. *** #### **Connector** A prebuilt integration with a third-party platform (such as AWS, OpenAI or Replicate). Enables Wundaflow to execute functions using customer-provided credentials without needing to host infrastructure. *** #### **Execution** A specific instance of a workflow being run with defined inputs. Executions have a lifecycle and can be monitored or controlled via API. *** # Workflows Typically, when we refer to a *Workflow* we're actually talking about either a Workflow Definition or a Workflow Run. ### Workflow Definition A Workflow Definition outlines the steps that a Workflow Run will perform. In Wundaflow, a Workflow Definition is named using kebab-case, e.g.: `send-notification-email`. Workflow Definitions are created within the Wundaflow UI and are made up of at least one Workflow Task. Each Workflow Definition can be viewed in a similar way to a step-function - that is, each task (or, step) must execute successfully before the workflow will move to the next. #### Workflow Definition Versioning As with all engineering projects, Workflow Definitions may need to change over time. We support versioning using a simple incrementing integer. Workflow Runs can be started using **latest** or by specifying the `version` number required. ### Workflow Run A Workflow Run is a specific instance (execution) of a Workflow Definition. Each instance of a Workflow Run can be identified within Wundaflow using a prefixed unique ID (e.g., `flow_4eC39HqLyjWDarjtT1zdp7dc`). Each Workflow Run starts with an injected context that is persisted throughout the life of the Workflow Run. For a Run triggered from a blockchain event, this would include the related `transaction` and `block` objects. # Tasks Tasks are the basic unit of work in a Workflow. Similarly to Workflows, when a Task is referenced, it could be referring to either a Task Definition or a Task Run. ### Task Definition A Task Definition outlines what the specific step of the given Workflow Definition is responsible for executing. This could be, for example, interacting with a smart contract (calling a specific method), calling an API endpoint, invoking an AWS Lambda function or sending a notification email. A Task Definition is named using kebab-case (e.g., `my-task`). The default Task of any Workflow Definition is sending a webhook to your application's configured `webhook_url` using the `send-webhook` Task Definition. ### Task Run A Task Run is a specific instance (execution) of a Task Definition and will be attached to a Workflow Run. A Task Run is assigned a unique prefixed ID, e.g., `task_4eC39HqLyjWDarjtT1zdp7dc`. Task Runs are passed the Workflow Run context, which they can modify before returning the context to the Workflow ready for the downstream Task (if one exists). #### Task State A Task Run can be in any of the following states:
StateDescription
noneThe task is not yet ready to run (upstream tasks are still pending or failed).
pendingThe task is pending execution.
queuedThe task has been queued and is awaiting a Worker slot.
runningThe task is running on a Worker.
successThe task completed successfully.
shutdownThe task received an external signal to shutdown during execution.
restartingThe task received an external signal to restart during execution.
failedThe task failed.
pending_retryThe task failed but has retry attempts remaining.
# Workers We reference *Workers* within our documentation as a method of conveying the internal processes that execute your *Workflows* and *Tasks*. In general terms, you do not have to be concerned about how Workers operate and can therefore consider them essentially a 'black box'. ### Security Workers operate within a restricted Virtual Private Cloud. Worker instances do not have public IP addresses and cannot be accessed directly from the Internet or have direct outbound access. Task Executions are sandboxed and cannot interfere with Task Executions attached to other Workflows. # Triggers While workflows can be instantiated using our API, calling them from existing web2 applications is only one use-case. {% hint style="info" %} Triggers start new workflow executions, but you can also send [signals](/core-concepts/signals) to already running workflows. {% endhint %} There are four methods to trigger workflows in two categories: ### Off-chain triggers 1. **API triggers.** See the API documentation in the left navigation. 2. **Webhook triggers.** Similar to API triggers, webhook triggers allow you to start workflows from any 3rd party app that supports webhook notifications. Just create a custom webhook endpoint in the Wundaflow UI and you're good to go. 3. **Time-based triggers**. Workflows can be executed on a given date-time or, using cron-syntax, regularly on any schedule down to per minute. ### On-chain triggers 1. **Logic triggers**. Workflows are executed based on custom logic conditions being met on the blockchain. *Supported: Bitcoin, Ethereum, Base, BNB Chain, Polygon*. #### Logic trigger examples: * **Smart contract address or addresses**. A workflow is executed on any interaction with the contract address.
* **Smart contract balance**. A workflow is executed when a given balance is reached.
* **Smart contract method**. A workflow is created when a specific method is called on a given smart contract address. This is particularly useful for creating NFT-connected workflows or those involving gaming assets. We use this extensively for both Wundaflip and Blobbs NFT.
* **Transaction amount**. A workflow is created based on the value of a given transaction in the native currency/token.
* **Block number**. A workflow is created when the block number is mined. # Signals There will likely be instances where you want to create a long-running workflow that waits for a specific action to occur from outside the blockchain. This is where *signals* come into play. # Webhooks *Not to be confused with an inbound webhook attached to a webhook trigger, we also support sending (outbound) webhooks when events occur within your Wundaflow account.* By consuming webhooks, your Web 2.0 application can react in near real-time to events on the blockchain. Using logic triggers, watching for events as granular as from a specific wallet or to a specific contract method become trivial. As webhooks are sent using resilient workflows, even if your application is down or network congestion prevents the webhook being acknowledged, you can be sure that you will never miss a notification. Automated retries and API polling as backup mean events are never lost or duplicated. You can configure your webhook URL from within the Wundaflow console. ### Event properties Webhooks are delivered as JSON POST requests and adhere to the Standard Webhooks schema (see standardwebhooks.com):
ParamDescription
typeThe event type (in dot notation).
timestampThe original date/time of the event in YYYY-MM-DD HH:MM:SS TZ format.
dataAny specific data related to the event. For blockchain events, this will include the block and transaction objects.
#### Example payload ```json5 { "type": "workflow.started", "timestamp": "2023-04-10 14:31:05 UTC", "data": { "id": "flow_4eC39HqLyjWDarjtT1zdp7dc", "workflow_name": "send-notification-email", "workflow_version": "latest" } } ``` ### Webhook headers In addition to the payload (body) of the webhook, we also send 3 important headers along with the request: * `webhook-id`: the unique webhook identifier. * `webhook-timestamp`: integer unix timestamp of the webhook attempt (seconds since epoch). * `webhook-signature`: the signature(s) of this webhook We sign all webhooks so that you can be confident that the event did indeed originate from Wundaflow. You should never trigger any logic related to a webhook without first completing verification of the signature. ### Idempotency ID's In a similar way that we support idempotency on API calls to avoid duplicate processing, the `webhook-id` can be used in the same manner. Our webhook system promises **at-least-once delivery**, but this can mean that under certain network or system conditions you may receive multiple requests. For example, an error within your webhook receiver may mean that a request was received and queued, but a non-200 HTTP response was returned. Wundaflow will consider this request failed and retry. In this and similar circumstances, you can rely on the `webhook-id` to decide if processing has already taken place or not. # Retry policies ### Webhooks Webhooks expect an HTTP 2xx response to be considered delivered. By default, we will attempt delivery 5 times before marking a webhook as failed using an exponential back-off algorithm. Failed webhooks can still be collected from the /webhook/poll endpoint. Webhooks adhere to an at-least-once delivery policy. This means that we will potentially retry even if your app acknowledges receipt (e.g, if network conditions prevent the request completing, for example). ### Tasks Workflow Task Runs will be retried if they do not return a valid success or error response. While this is handled for you with native tasks, if deploying serverless functions within your own account or using embedded JS tasks, you must always return appropriately to avoid retries. Should we see a retry level >30%, we will disable your Task Runs and this will render all related Workflow Runs inoperable also. # Wallets For use-cases that involve blockchain interaction, either within a single chain or on multi-chain workflows, hot wallets will need to be generated to receive/send transactions. Each wallet is created with it's own private key, which is stored securely within our secrets vault. While wallets can be persistent and used repeatedly, we recommend that you adhere to a single-use principal and ensure that no funds are left in the wallet by the end of your workflow runs. For multi-tenant systems - such as a CEX that needs to receive user deposits - creating a new deposit address for every transaction may not be desirable, however you can still maintain the 'zero funds' method by automatically sweeping remainders to a central custodial address at the end of every workflow. # KV Store Having access to a low-latency key-value datastore is highly desirable for many workflow types. Especially so if you plan to build your app entirely on top of Wundaflow and do not maintain any of your own infrastructure. Our native JavaScript Task has access to two types of KV Store: #### Context KV Store (CKV) This datastore only persists within the context of the current workflow. Data stored within the Context KV Store will therefore not be accessible from any other workflow run. #### Global KV Store (GKV) As the name suggests, this datastore is backed to disk and is accessible from any workflow run in your account. This is useful for storing data associated with contracts/wallets that's too large to keep on the blockchain, or things such as long-running atomic counters. Additionally, the Global KV Store is also accessible from outside of workflows via API calls. This means that you can read and write data directly from your web2 application for use within your smart contract workflows. # API Methods {% hint style="danger" %} The public API spec is still being finalized. Check back soon for details of endpoints and other related documentation. {% endhint %} # Execute a workflow {% hint style="danger" %} The public API spec is still being finalized. Check back soon for details of this endpoint. {% endhint %} # Pause a workflow {% hint style="danger" %} The public API spec is still being finalized. Check back soon for details of this endpoint. {% endhint %} # Resume a workflow {% hint style="danger" %} The public API spec is still being finalized. Check back soon for details of this endpoint. {% endhint %} # Cancel a workflow {% hint style="danger" %} The public API spec is still being finalized. Check back soon for details of this endpoint. {% endhint %} # Check workflow status {% hint style="danger" %} The public API spec is still being finalized. Check back soon for details of this endpoint. {% endhint %} # Poll for notifications {% hint style="danger" %} The public API spec is still being finalized. Check back soon for details of this endpoint. {% endhint %} # Generate a wallet address {% hint style="danger" %} The public API spec is still being finalized. Check back soon for details of this endpoint. {% endhint %} # Read from KV Store {% hint style="danger" %} The public API spec is still being finalized. Check back soon for details of this endpoint. {% endhint %} # Write to KV Store {% hint style="danger" %} The public API spec is still being finalized. Check back soon for details of this endpoint. {% endhint %} # Authentication The Wundaflow API uses API keys in order to authenticate requests. You can view and manage your API keys within the API Console. In order to authenticate, you should send your API key within the header of the request using HTTP Basic Auth. Provide the API key as the basic auth username. You do not need to provide a password: `Authorization: Basic`` `**`your-api-key`** All API requests should be made over HTTPS. Calls using plain HTTP will fail. ### API Key Scopes You can create multiple API keys within the API Console and can scope them according to their specific requirements. For example, yuou may choose to enable access to read-only endpoints for a given API key that may run on an untrustworthy host. # Connectors {% hint style="danger" %} The public API spec along with native connectors is still being finalized. Check back soon for details. {% endhint %} For public launch, we'll have native connectors for AWS, GCP, Azure, IPFS and OpenAI (ChatGPT). Based on customer demand, we'll extend connector support accordingly. Keep checking back for more info. # Secrets In order for some Connectors to operate, they require credentials to be stored within Wundaflow. For example, to use any of our Amazon Web Services Connectors, you will need to store AWS IAM credentials. We take the security of 3rd party credentials very seriously. All credentials are stored encrypted within a secrets vault (AWS Secrets Manager) and the web UI/front-end only possesses write access. Workers, conversely, only have read access. Our Worker instances are entirely decoupled from the front-end and API, do not have public IP addresses assugned and do not have direct internet access. ### Best practice We recommend that you adhere to the following best practices when sharing credentials with Wundaflow: 1. Use the Principle of Least Privilege (PoLP). Always give the user the minimum possible permissions scope in order to facilitate the required actions. For example, in the case of the AWS Lambda connector, the IAM user should have execute permission to only the specific function name you need to call in the specific region specified.
2. Periodically rotate credentials and check permissions. Do not 'set and forget'.
3. Configure access logging and monitor for any unexpected activity. If discovered, immediately revoke the credentials. # Errors Wundaflow uses standard HTTP response codes to indicate success or failure of an API request. Generally, codes in the `2xx` range indicate success, codes in `4xx` range indicate an error that failed due to the request params, and codes in the `5xx` range indicate an error with Wundaflow's platform. Most `4xx` error codes will also return a JSON response body that indicates the exact issue with the request.
HTTP statusSummary
200 - OKEverything was OK.
400 - Bad RequestRequest was not accepted, often due to missing or incorrect params.
401 - UnauthorizedMissing, revoked or invalid API key.
402 - Request FailedThe params provided were valid but the request failed.
403 - ForbiddenAPI key provided does not have permission to perform the requested action.
404 - Not FoundThe requested resource could not be found.
409 - ConflictThe request conflicts with another request or the resource is not in the correct state.
429 - Too Many RequestsYou are being rate limited, slow down your requests or ask for a rate increase.
500 - Server ErrorSomething is wrong on Wundaflow's side. Try the request again or contact support.
# Tokenomics {% hint style="danger" %} This page should be considered as **work in progress**. The information presented here is yet to be finalized. {% endhint %}
### $WUNDA - Utility Token $WUNDA is an ERC-20 utility token operating on the Ethereum blockchain. It will be the primary currency of the Wunda ecosystem, including the Wundaflow SaaS platform and the future Wundaverse gaming landing-zone. * 2,000,000,000 total supply * No buy/sell tax * Utility token Distribution:
Description%TokensVestingComment
Public sale49980MPublic sale
(unsold tokens burned).
Staking pool7.5150MStaking rewards.
Lottery pool7.5150MLottery airdrop rewards.
Liquidity8160MReserved for exchange liquidity.
Talent acquisition7140M2YReserved for hiring incentives.
Partner incentives360M1YFor distribution as part of commercial agreements.
Competition pools360M1YTo fund prize pools and new games.
Treasury15300M5YFor long term project ecosystem support, grants and mentorship.
*(Treasury has 1Y cliff + 4Y linear vesting. All other vesting is linear.)* $WUNDA will be sold in a tiered pre-sale ranging from 0.007 USD per token to 0.01 USD per token across 5 stages. We expect to list on our first DEX at 0.011 USD. This listing price would give $WUNDA a market cap of 22,000,000 USD. There will be two staking opportunities that are designed to discourage and alleviate sell pressure of $WUNDA tokens post-launch (see [Staking pools](/token/reward-pools)). #### Token burn All tokens used as payment for Wundalab products (Wundaflow SaaS and/or future related products) will be subject to a 12% burn until the total supply is reduced to 400M tokens. ### $WUNDX - Rewards Token $WUNDX is an ERC-20 rewards token operating on the Polygon chain. It has no value outside of the Wunda ecosystem but can be exchanged in the upcoming WundaShop for merch, game boosts, upgrades and more. {% hint style="info" %} **Note:** *$WUNDA and $WUNDX may be used to make purchases within the WundaStore and other Wundalab-operated destinations, but not on third-party destinations. These tokens do not constitute electronic money under the EU Electronic Money Regime.*\ \ *Additionally, this website does not adhere to the UK Financial Promotions Regime and is not intended for UK audiences. If you are accessing this website from the UK, please exit immediately.* {% endhint %} # Reward pools {% hint style="danger" %} This page should be considered as **work in progress**. The information presented here is yet to be finalized. {% endhint %} We appreciate the desire of the community will be to encourage token holding and are offering two great opportunities for holders to stake tokens with guaranteed yields. Our tokenomics reserves 300M tokens purely for this purpose. ### Option one: reward pool The reward pool operates much likely a typical staking pool, however the purpose is to decrease your token cost. We will accept a maximum of 500M tokens (50% of the public sale) and will be open immediately on launch day for a 24 hour window. After this date there will be **no further opportunity to join**. The reward pool will lock tokens for 180 days and provide 130% of staked value in return via an airdrop. For example, if you stake 1000 $WUNDA then you will receive 1300 $WUNDA back. We have 150M tokens reserved for the staking pool. ### Option two: lottery airdrop After the reward pool closes, we will begin the lottery airdrop. We have 150M $WUNDA tokens allocated and will produce a 1M token winner every Sunday at 21:00 UTC until the lottery pool is empty. A second winner will also be drawn that will receive 100,000 $WUNDX. {% hint style="info" %} While this is called a lottery, there is actually no need to manually enter and there are no fees associated either. The lottery airdrop is a random bonus and requires no specific action on your part. {% endhint %} Wallets will be automatically entered. To qualify they must: * Hold a minimum of 25,000 $WUNDA. * Have held at least 25,000 $WUNDA for the previous 60 days. Every 30 days, the entry requirement will increase by 1500 $WUNDA. {% hint style="danger" %} **Note:** *this website does not adhere to the UK Financial Promotions Regime and is not intended for UK audiences. If you are accessing this website from the UK, please exit immediately.* {% endhint %} \
# Intro As a web3 infrastructure vendor, we believe that it's of utmost importance to 'dog-food' our own product. The Wundaverse is our hyper-casual lo-fi games launchpad. Our games are powered via on-chain smart contracts connected to the Wundaflow platform and serve as a showcase of our core features.
wundaverse logo
### What is a hyper-casual game? Hyper-casual games are characterized by lightweight, instantly playable games that players revisit often because of short session length and fun game mechanics. They often have very minimal user interfaces and can be played ad-hoc without any detriment to playability. In terms of GameFi, hyper-casual play-to-win games allow the player to play on their own schedule - often only playing a single round at a time - with consistent win odds. ### Zero-trust games We're championing **zero-trust games**, but what is that exactly? While Wundaflow allows us to build fun and performant web2 interfaces and back-ends for general interaction, we want to ensure that - at a minimum - **all payout mechanisms exist 100% within the on-chain smart contract**. If Wundalab cease to exist then users can still collect their funds and, in most cases, could still continue to play the games too. We're achieving this with innovations such as, amongst others, tight variable packing in our NFT collectibles in order to store traits entirely on-chain. ### Future While we'll be focusing on the 2D Wundaverse initially, we will quickly move into the 3D Wundaverse (desktop/mobile gaming) and finally into the 4D Wundaverse (AR, VR and metaverse/immersive worlds) when the time is right. Simply put, we have big plans for the future of the Wundaverse. # Randomness Typically, where a smart contract requires randomness, the use of an external oracle is the recommended route. Chainlink VRF is the dominant provider here and the process is simple, as per the steps in their own documentation. However, in practice the use of Chainlink VRF has detrimental effects in both **game play** and **cost to play**. We conducted a detailed UX test in November 2022 involving 1000 simulated game plays using typical real-world Chainlink VRF callback delays. * A typical VRF play fulfillment takes an average of 12 blocks, but with 8% taking upwards of 15 blocks and 0.2% going unfulfilled entirely. * Using our in-house blockchain event monitoring solution (“wundaflow”), a typical play takes just 5 blocks to fulfill, with <0.5% (1 in 200) taking over 10 blocks and, importantly, **0% non-fulfilment**. The results also show that the churn of first-time players was 5% greater for Chainlink VRF plays than non-Chainlink VRF plays. Ultimately, each of those players could have had (1) significant LTV (lifetime value) to the Wundaverse, and (2) aided customer growth through future word of mouth acquisitions. In terms of costs; a typical Chainlink VRF play costs the player **40% more Wei** than a non-Chainlink VRF play. Wundalab also needs to cover the cost of funding the contract with LINK (Chainlink’s native token), further increasing running costs and eroding prize pools. In addition to UX and cost analysis, we conducted further research into potential attack vectors on our contracts without a VRF in order to determine the risks involved and develop any necessary mitigations. These attack vectors included: * Malicious miners/validators * Coordinated malicious players * Internal malicious actors (employees) Based on this research, we ultimately settled on a unique dual-randomness approach, with on-chain randomness using future blockhashes being used for standard plays and a Verifiable Delay Function (VDF) using Wundaflow being used for both large stakes and also for any plays that could result in jackpot payouts. {% hint style="info" %} On wundaflip, this means that on-chain randomness is used on winning streaks of 0-9 and VDF for flips 10 and 11. {% endhint %} **How does on-chain randomness work?** *We use a simple time delay method whereby the outcome will be determined on a future blockhash. As the player must stake their bet prior to both the block and block hash being known, there is no way for them to determine or manipulate the result. A simple way to look at this process is that it’s similar to sports betting where the player must guess the final score prior to the game being played.*
**What if the player is also the miner/validator?** *As we do not determine the fulfillment block until the stake is made, a malicious miner/validator would need to be able to control an arbitrary future block at will in order to control the result. We fulfill bets at anywhere from block n+2 up to block n+5.* **What if the house is malevolent?** *The house cannot control the choice made by the player. The house also has no control over which future block is used for the result fulfillment, or any control over the transactions that make up that block and ultimately determine the blockhash.* **What if I make two bets in the same block with different wallets, will they have the same result?** *No. We use two methods to ensure each game is unique. Firstly we choose the result block during the play function call, which can be anywhere from block n+2 to block n+5. Secondly, the result is determined using the blockhash and the wallet address as a seed; as each wallet is different, the result will be unique for each invocation. In the case of a coin flip: two individual wallets may generate the same result on one flip, and different results on the next (therefore, the divide and conquer brute force strategy would not work).* **Why use a VDF instead of Chainlink VRF?** *We believe that VDF is superior to Chainlink VRF, not least because it's cheaper and more performant, but also because it doesn't rely on the assumption that oracles are not compromised. You can read more about our reasoning* [*here*](/wundaverse/randomness/verifiable-delay-function-vdf)*.* *Additionally, by using Wundaflow VDF the player can instantly see and verify the proof in-game.* # Verifiable Delay Function (VDF) A Verifiable Delay Function (VDF) is a cryptographic tool designed to produce a result that takes a specific amount of time to compute, even with significant computational resources, but can be quickly and easily verified by others. This characteristic makes VDFs particularly useful in scenarios where it's important to ensure that a certain amount of time has passed before a result is known, while still allowing for rapid verification.​ ### 💡 How Our VDF-Based Randomness Works To ensure fairness in our games, we use a **Verifiable Delay Function (VDF)** combined with the **blockhash** of the transaction’s block to generate randomness that is: * **Unpredictable before the bet** * **Unmanipulable by the user or the house** * **Publicly verifiable by anyone** #### 🔐 Why Not Just Use Random Numbers? Traditional randomness methods can be **gamed**: * The **user** could precompute outcomes if they know the randomness algorithm * The **house** could bias results if it controls the random seed We solve this using cryptographic guarantees, not trust. #### 🧠 What is a VDF? A **Verifiable Delay Function (VDF)** is a cryptographic function that: * **Takes a fixed amount of time to compute**, no matter how much hardware is thrown at it * **Returns a result that is fast to verify**, even on-chain * **Can only be computed once the input is known**, so no precomputation is possible Think of it like a tamper-proof hourglass for randomness: once started, the output can only appear after a delay, and everyone can confirm it’s legit. #### 🧪 Our Randomness Source 1. **User places a bet**, which is included in block `N` 2. After confirmation, we extract the **blockhash of block N.**\ `block_hash = blockhash(N)` 3. We construct a unique input using:\ `input = keccak256(user_address || stake_amount || block_hash)` 4. We compute:\ `output = VDF(input) proof = VDF_proof(input, output)` 5. We use the output to generate a hash consistent with a blockhash and pass this back to the on-chain contract to use as a result source. #### ✅ Why This Is Fair * The **blockhash isn’t known until after the bet is mined** — so no one can predict or manipulate it ahead of time * The **VDF forces a minimum delay** between input and output * The **output and proof are public**, so anyone can verify the fairness #### 🚫 Why We Don't Use Chainlink VRF While Chainlink VRF is a popular solution for on-chain randomness, we chose not to use it due to the following concerns: | Concern | Chainlink VRF Limitation | | ------------------------------------ | ------------------------------------------------------------------------------------------- | | **Dependency on third-party oracle** | Requires trusting Chainlink nodes to return the randomness | | **Cost** | Each request incurs high gas and LINK token costs | | **Latency** | Responses are asynchronous and can take several blocks | | **Opacity** | Users cannot verify how long the oracle took to respond | | **Decentralization tradeoff** | Although decentralized at the network level, randomness comes from a single node at runtime | By contrast, our VDF-based system: * Is **fully deterministic and trustless** * Doesn’t rely on any third-party service or token * Is **instantly auditable and reproducible** by anyone * Guarantees **delay and transparency**, without external dependencies *** We believe this approach offers **maximum transparency, fairness, and cryptographic integrity**, without introducing the risks and costs of external oracles. ### ### Why We Use RSA-2048 and Wesolowski Proofs (the technical bit) We use an RSA group with unknown factorization—specifically, the well-known [RSA-2048 challenge modulus](https://en.wikipedia.org/wiki/RSA_numbers#RSA-2048)—to ensure that the Verifiable Delay Function (VDF) cannot be parallelized or shortcut. The security of this approach relies on the mathematical difficulty of factoring large semiprime numbers, a widely trusted cryptographic assumption. To make the result quickly verifiable without repeating the expensive computation, we generate a Wesolowski proof, which allows anyone to validate the VDF output in constant time. This combination ensures both guaranteed computational delay and fast, trustless verification, making it ideal for provably fair randomness generation in decentralized applications.\ [Read more on RSA modulus and the RSA Factoring Challenge](https://en.wikipedia.org/wiki/RSA_numbers#RSA-2048) # Blobbs NFT # WundaGames WundaGames is the portal for accessing our meta-arcade; the destination for fun instant-feedback hyper casual bet-to-win titles.
# Wundaflip A coin flip game with a twist on BASE and Polygon. Coin flip games are common, with Degen Coin Flip probably being one of the most widely known in the crypto space. The premise is simple, the user stakes an amount and guesses the outcome of the coin flip (heads or tails). If the user guesses correctly they win double their stake (minus the house rake), if they guess incorrectly then they lose the stake entirely. All coin flip games suffer from the same problem though; they're a bit boring. Each game is the same and eventually, after a loss there's not much incentive to continue. Wundaflip is different. Returns on an individual winning coin flip are slightly less than your typical game at 196%, BUT the extra fees go straight into the prize pool. The prize pool inflates with every play and a jackpot win takes home 50% of the pool. We modelled millions of plays and estimate that jackpots could reach a huge $400,000 USD! Winning the jackpot is simple, although easier said than done - **just guess 12 correct coin flips in a row**. But wait, there's more: * Choose your path, to jackpot or no jackpot. To continue a winning streak you must stake at least 10% more than your previous flip. * Get a win streak boost, free! 1% of plays randomly gain a free win streak boost, meaning one less guess to hit that jackpot. * Earn extra lives through playing regularly. Only one extra life can be used during any single winning streak and only be played on a win streak of 4+ flips (played automatically if available). * Guaranteed on-chain payouts. There is zero reliance on Wundalab to fulfill distribution of winnings. {% hint style="info" %} This game uses random outcomes but i**s not a game of chance** as the timing of your flip will directly influence the result. Read more about how Wundaverse games fulfill randomness to maintain balance between gameplay and low gas fees. {% endhint %} ### Wundaflow integration Coinflip is built entirely on-chain and can even be played on the command-line if desired. However, to provide the best UX possible, the web UI and back-end utilize Wundaflow extensively. When a gameplay is initiated, a workflow creates a dedicated websocket for the wallet address. A second workflow listens for contract method calls on the active chain and turns them into events that are delivered as a stream via the websocket. The UI (built using Vue.js) handles inbound events in real-time and updates various parts of the game space accordingly. For flips using on-chain randomness, the user can simply collect winnings anytime after the the block is available, however for [VDF randomness](/wundaverse/randomness/verifiable-delay-function-vdf), a third workflow automatically calls the `fulfillVDF()` method once the result and proof are computed. Finally, a fourth workflow allocates extra lives to players that play regularly, this is triggered via the wundaflip back-end ingesting webhooks. Extra lives add a further element of skill to the game as you must time when they're played with great strategic precision. # DISCLAIMER For the avoidance of doubt, Wundalab does not provide any investment advice nor does it execute or facilitate transactions on behalf of its users outside of workflows specifically configured by those users. Wundalab’s business model is to provide infrastructure (via Wundaflow) as well as exciting and fun hyper-casual gaming (via the Wundaverse) to the web3 community only. {% hint style="danger" %} **Note:** *this website does not adhere to the UK Financial Promotions Regime and is not intended for UK audiences. If you are accessing this website from the UK, please exit immediately.* {% endhint %} *This website and any downloadable material are intended for information purposes only and does not constitute investment advice or any recommendation to invest in cryptocurrencies or digital assets. Cryptocurrencies and digital assets may be unregulated in your jurisdiction. The value of cryptocurrencies and digital assets may go down as well as up. Any profits may be subject to capital gains or other taxes applicable in your jurisdiction.* **1. Geographic Restrictions**\ This project is **not intended for individuals or entities located in the United Kingdom** or other jurisdictions where participation in this project or interaction with our token may be restricted or regulated. Where we are able to do so, access to our website, services, and token offerings is **geographically restricted**, and we actively **block IP addresses** from these jurisdictions. If you are accessing this website or using our services from a restricted jurisdiction, you do so in violation of our terms and at your own risk. **2. Token Use and Functionality**\ Our token is designed and intended solely as a **utility token** within our ecosystem. The token is used to provide access to services and credit within our platform, and it holds **no intrinsic financial value** outside of this ecosystem. * The token is **not an investment** and is not meant to provide any expectation of profit or financial return. * Token holders can only use the token to interact with our platform and services and cannot exchange the token for money, external assets, or other forms of financial gain. * Any **staking rewards** are provided solely as **additional service credits** within the platform and are not interest, dividends, or profit-sharing mechanisms. Users who stake their tokens receive additional credit for services at the end of the staking period. These rewards are intended to **enhance engagement** and **reward loyalty** within the ecosystem. **3. Staking Program**\ Participation in the **staking program** is voluntary and solely for the purpose of earning additional **service credit** within our platform. * Users who choose to stake their tokens for a defined period (e.g., 3 months) will receive a **10% bonus credit** in tokens at the end of the staking period. This reward can only be used for platform services and holds no external value. * This staking program is not an investment vehicle, and participants should not expect any financial return from staking their tokens. All rewards are service-related and can only be used within the ecosystem. **4. Secondary Market Trading**\ While we cannot control external platforms or decentralized markets, our tokens are intended solely for use within our ecosystem. Any trading of the token on **secondary markets** is done without our involvement or endorsement, and we do not support or facilitate such practices. * Tokens are **non-custodial** and we have no means of restricting secondary trading activities. However, we do not market the token as a tradable or speculative asset. * The token’s purpose remains to provide access to our services, and any interaction with third-party exchanges or markets is outside the scope of our project and at the user’s own risk. **5. Consumer Protection**\ This project provides **no guarantees** of financial returns, speculative benefits, or liquidity for token holders. The token is meant to serve as a means of access to our ecosystem services, and **no monetary or investment benefits** are implied or promised. * Users should understand that the token’s value is confined to its use within the platform, and there is no expectation of profit or financial growth. * All participation in the platform is voluntary, and users should assess their involvement based solely on the utility and services provided, not on speculative or financial expectations. **6. Terms of Service and Compliance**\ By using this website or participating in the project, you agree to the terms outlined in this disclaimer. It is the responsibility of users to ensure that their participation is compliant with the laws of their jurisdiction. * The project operates within the framework of its defined purpose and is intended for individuals seeking to use its services within the platform. * The project does not promote or facilitate speculative investment activities, and all token interactions should be viewed as part of the **utility-based ecosystem** rather than an external financial asset. ### Risk Statement Understanding risk is an important consideration for protecting capital, so before deciding to purchase the $WUNDA token prospective holders should carefully weigh their risk appetite. Purchasing $WUNDA tokens entails a degree of risk and may lead to the loss of a considerable or the whole of the capital advanced, as delimited by the amount of purchased $WUNDA tokens. Before purchasing, prospective holders should carefully consider the risks identified in this whitepaper, as well as any other risks not anticipated or included in this document. The regulatory status of crypto assets may vary depending on your jurisdiction. It may be possible that future laws, regulation or policies relating to crypto assets may be implemented that affect token holders' acquisition, rights, and ability to buy, sell, convert or use crypto assets such as the $WUNDA token. You should only purchase $WUNDA tokens if you fully understand the tokenomics of the $WUNDA token and the $WUNDA ecosystem. Crypto assets are not regulated as financial instruments and there is no refund or compensation available from corresponding regulatory bodies. Crypto assets can be the subject of expropriation or theft. There may be no remedy if there is a successful attack by malicious actors against the Ethereum Chain on which the $WUNDA token is built. Additionally, hackers may attempt to interfere with the $WUNDA platform directly in a number of different ways such as malware attacks, distributed denial of service attacks and consensus-based exploits. These attacks could lead to a loss of $WUNDA tokens or the loss of the ability to access $WUNDA tokens. Readers should consider consulting professionals such as an independent financial adviser, a tax consultant, accountant or a lawyer in order to fully satisfy themselves regarding any outstanding matter related to the purchase of the $WUNDA token.