A developer connects a wallet, posts a screenshot, and receives the points for “integrating the partner’s package.” The partner checks the repository later and finds no call to that package. The quest measured a social action while the partner needed technical activation.
A developer quest platform assigns, tracks, and verifies technical tasks during onboarding, education, hackathons, grants, or partner programs. A software development kit (SDK) is the package and documentation a product provides for integration. A useful quest names the artifact a developer must produce and the behavior a verifier must observe. A verifier is the check or service that observes that behavior and records whether it passed, failed, or was skipped.
Code verification means that completion depends on a build, test, runtime check, browser run, or deployment result. It gives the platform an observable question: did this defined behavior pass under these conditions?
An evaluation is a repeatable check against an expected result. A trace is the ordered record of a run, including the inputs, actions, outputs, failures, retries, and artifacts needed to inspect it.
An API, or application programming interface, is the documented boundary through which one program requests data or actions from another.
Blueprint Agent is Tangle’s AI coding workspace. Its public documentation describes an agent that edits and runs code in a browser-based development environment while the developer reviews and steers the work. That workspace can help a developer finish a quest, while the verifier remains the authority on whether the quest’s behavior occurred.
A quest is a small contract
The word “quest” can describe anything from reading a tutorial to deploying a service. The platform needs a narrower contract for technical work.
| Field | Question it answers |
|---|---|
| Outcome | What behavior should exist when the quest is complete? |
| Starting state | Which project, dependencies, network, and accounts are supplied? |
| Inputs | Which request, event, file, or user action does the verifier use? |
| Expected result | Which value, state change, screen, or artifact counts as success? |
| Failure cases | What invalid input or unavailable dependency should the developer handle? |
| Evidence | Which output, diff, trace, Uniform Resource Locator (URL), or report can a reviewer inspect? |
| Limits | What time, network, account, or resource constraints apply? |
“Learn the protocol” fails this test.
“Add a quote endpoint that returns an amount and expiry, reject an expired request with a documented error, and pass the supplied checks” gives the developer a finite target.
The task should fit in one focused session. If the verifier needs to understand an entire product before it can decide, the quest needs to be split.
Order quests by evidence, not points
A developer usually moves through a sequence like this:
environment starts
-> package installs
-> first documented call succeeds
-> product-specific behavior passes
-> expected failure is handled
-> user-facing or deployed result is observableEach stage answers a different question. An install proves that the workspace can reach the dependency step. An API call proves that the request can cross the interface. A product-specific behavior shows whether the integration crossed the connection boundary. A failure case shows whether the integration understands the contract. A deployed result shows that the work reached a reviewable target.
A testnet is a blockchain network used for testing with non-production assets and state.
Use the stages to diagnose friction. Do not add points to a weak check and call the resulting number progress.
| Quest | Primary evidence | Common false positive |
|---|---|---|
| Install the SDK | Lockfile and import check | A package is installed but never used |
| Call the API | Request and expected response | A mocked response hides a bad request |
| Add a contract interaction | Testnet state or event | The test only checks that a transaction was sent |
| Build a wallet flow | Provider state and browser assertions | A screenshot shows the wrong network |
| Deploy the service | Artifact, target, health result | A URL points to an old build |
| Fix a bug | Regression test fails before and passes after | The test never exercises the reported bug |
The verifier should treat missing evidence as a failure or skip. It should never infer a pass from an absent observation.
A worked quest for a paid job
Consider a Blueprint that exposes a document classification job. A Blueprint is a reusable definition of a service, including its jobs, inputs, outputs, executable artifact, and optional protocol rules. A Service is one configured running instance of the Blueprint. A Job is one callable unit of work inside a live Service.
The partner wants developers to build a small client that pays for one job and renders the result. The quest can be divided into four checks.
- The client sends an unpaid request and receives a payment requirement.
- The client signs the requested payment and retries the request.
- The response contains the expected classification fields.
- A malformed document produces a documented error without displaying a false success.
x402 is an open payment standard that uses Hypertext Transfer Protocol (HTTP) 402 Payment Required to communicate what a client must pay before receiving a resource.
The x402 HTTP 402 documentation describes the payment requirements and headers used by current versions of the protocol.
An x402 check can prove that the payment exchange reached the service.
The result check must still prove that the job returned the expected fields.
The completion packet could have this shape. This JavaScript Object Notation (JSON) is an illustrative contract for a partner-owned verifier.
{
"quest": "paid-classification-job",
"workspace": "clean-starter-v3",
"checks": [
{ "name": "payment-required", "status": "passed" },
{ "name": "payment-retry", "status": "passed" },
{ "name": "result-schema", "status": "passed" },
{ "name": "malformed-input", "status": "failed", "reason": "error was rendered as success" }
],
"artifact": { "target": "preview", "version": "candidate-7" },
"trace": { "id": "redacted-for-review" }
}The quest is incomplete because the failure behavior is wrong, even though three checks passed. This is the practical value of separate check results. One score would hide the behavior that the partner needs to fix.
Let an agent help without making it the judge
An agent profile is a saved set of choices for an agent run, including the model, instructions, tools, permissions, and budget. A runtime is the machine and software that apply those choices, mount the project, start processes, and enforce resource and network limits.
The profile can give the agent the partner docs, starter files, test command, and a browser tool. The runtime can keep the workspace isolated and preserve command output between attempts. The developer can accept, reject, or edit the agent’s changes. The verifier should run independently of the agent’s final explanation. Tangle’s Sandbox runtime is the isolated workspace that provides the files, processes, and policy boundary for the run.
This separation protects the meaning of the quest. If the assistant writes a test that asserts its own mocked output, the verifier should run against the partner’s fixture or service boundary. If the assistant claims that a deployment succeeded, the verifier should query the named target and record the artifact version. If the agent cannot access a required tool, the quest should expose that environmental failure rather than quietly changing the task.
The public Tangle AI documentation describes profiles for models, tools, and budgets, isolated sandboxes, and an evaluation loop that feeds run results back into workflows. The agent profile delivery guide explains why a selected execution path must declare which profile settings it can deliver. The Developer Onboarding Platform With Code-Verified Quests article shows how these checks become activation evidence for a partner. For a judge-facing version of the same design, read Crypto Hackathon Platform For Code-Verified Builds.
Save the path as a trace
A trace can include the starting project, agent actions, tool calls, file diff, command output, evaluation results, retries, and final artifact.
The trace gives each failure a place to live.
| Failure | Trace evidence | Useful next action |
|---|---|---|
| Install fails | Package manager output and environment versions | Fix the starter project or version pin |
| API call fails | Request shape, response, and endpoint | Fix docs, authentication, or example code |
| Browser check fails | Network, page state, and screenshot | Fix flow or stabilize the test |
| Job times out | Job identifier, start time, and logs | Set a timeout or investigate the service |
| Deployment is stale | Target, version, and health result | Redeploy or expire the old URL |
| Verifier is flaky | Attempts and dependency status | Remove the unstable condition before scoring |
The trace should be useful without becoming an export of every private conversation. Redact credentials, personal data, private code, and sensitive prompts. Keep a reviewer-facing summary that names the relevant evidence and links to a protected full record when policy allows.
Give developers a way to challenge a result
An automatic result becomes part of a person’s onboarding record, grant milestone, or hackathon score. The platform needs an appeal path before it assigns a durable consequence.
The appeal does not need to bypass the check. It should preserve the original result, record the environment and dependency versions, rerun the same check when possible, and let a named reviewer explain an override.
| Appeal step | Record |
|---|---|
| Developer reports the issue | Quest identifier, run identifier, and failure description |
| Platform checks infrastructure | Provider status, blockchain endpoint health, browser version, and fixture availability |
| Check is rerun | Same source, inputs, profile, and verifier version |
| Reviewer decides | Evidence inspected and reason for keeping or changing the result |
| Quest is maintained | Whether the failure exposed a bad instruction or flaky check |
This process protects both sides. Developers have a way to recover from a provider outage or a false negative. Partners receive a record of weak checks instead of quietly overriding scores in a spreadsheet. If the same appeal repeats, fix the quest rather than training support staff to explain the same exception. Appeal data also shows whether the quest measures the intended skill. Many appeals about a missing dependency point to setup failure. Many appeals about a hidden fixture point to a verifier that was never explained. Many appeals about a generated implementation point to a task that needs a review or extension step.
Design the verifier before the reward
Points often distort quest design. A low-effort action gets a high completion rate, so the program treats that rate as success. The partner then learns that developers can collect points, not that they can use the product.
Start from the partner decision. If the goal is SDK activation, weight a real SDK behavior more heavily than workspace creation. If the goal is grant review, require an artifact and a reproducible check. If the goal is education, allow hints and partial progress while showing which behavior remains unverified.
The reward rules should not hide the proof rules. Publish whether a quest uses a unit test, API fixture, browser run, testnet transaction, or deployment check. Tell developers which data the verifier records and how they can challenge a false result.
Test the route a user will call
When a quest exercises a Tangle job, the test should follow the public job boundary. A job router maps a job identifier to its handler inside the Blueprint Runner, the process that receives job triggers and connects handlers to results. The runner also connects event producers, which turn events into job calls, result consumers, which handle job results, and background services that keep supporting processes alive. An RPC endpoint is a network address that accepts remote procedure calls, such as requests to a blockchain node.
Testing only the handler function can miss a wrong job identifier, input encoding, permission rule, or result submission path. Testing through the runner or documented client path makes the quest closer to the behavior a user will receive. The Blueprint Runner guide describes those runner components, and the public Blueprint repository contains runnable examples.
If the task requires confidential execution, an attestation is a signed statement from trusted hardware or an attestation service about the software and environment observed during execution. It can be one evidence field for the runtime boundary. It does not establish that the job output is correct. The quest still needs a result check. The Tangle execution confidentiality guide documents the policy boundary.
Failure cases that make quests dishonest
The verifier checks the implementation rather than the behavior. A test that searches for a function name can pass while the function is unreachable. Call the boundary and inspect the result.
The fixture is too friendly. A happy-path response can hide a malformed input bug. Include at least one invalid or expired case when the product contract has one.
The network is part of the score without being controlled. An RPC outage can turn a correct submission into a failure. Provide a fallback or separate infrastructure health from developer behavior.
The task is too large. A quest that mixes installation, architecture, payment, user interface, and deployment produces ambiguous failures. Split it into stages with separate evidence.
The agent finishes the task without developer understanding. Generated code can satisfy a narrow test while leaving the developer unable to maintain it. For grants or partner qualification, add a small extension or review step that tests the builder’s ability to change the result.
The reward creates a race to the easiest interpretation. State the product behavior, failure rules, and reviewer standard before the program begins.
What code verification can establish
Code verification establishes completion of a defined technical behavior under a defined environment. It can make developer progress more legible to the builder, the partner, and the reviewer. It can show whether a program’s setup and documentation work for a fresh workspace.
It cannot establish that the service handles authentication, authorization, malformed input, load, and operational failures in production. It cannot establish long-term usage or market demand by itself. It cannot distinguish careful original work from a generated implementation when the check is too narrow. It cannot eliminate the need for a human when money, grants, reputation, or access decisions depend on the result.
Use a reviewer override for meaningful programs. The override should record who made it, which evidence they inspected, and why the automated result was insufficient.
Publish the rule before the reward
Use a developer quest platform when the sponsor can name behaviors and maintain the checks that prove them. Use community tasks for community outcomes and label them accurately. Use code verification for technical activation. Use traces and reviewer access when the result affects rewards, grants, or partner qualification.
A quest is ready for builders when a new developer can understand the outcome, a clean workspace can run the verifier, an expected failure is visible, and a reviewer can tell exactly what passed.
What is a developer quest platform?
It is a system for assigning, tracking, and verifying developer tasks during onboarding, education, hackathons, grants, or partner programs.
What is code verification?
It is completion based on a build, test, runtime check, browser run, deployment result, or another observable technical check.
Is a wallet connection a code-verified quest?
It can be one small check. It does not prove that the developer integrated the sponsor’s SDK, contract, or product behavior.
Can an AI agent complete quests?
An AI agent can help edit files, run commands, read docs, and recover from errors. The developer and sponsor still need a clear task, a bounded runtime, and an independent verifier. For the broader product surface around those verified tasks, continue with Web3 developer tools for an agent workbench.
Are quests useful for grants?
Yes, when each milestone has an objective check and a reviewer can inspect the evidence before payment or follow-up.