Improve Token Contract + Tokenize Escrow UI

[techrebelgit]

Repo: tokenization-hack (monorepo)
Area: Soroban · Token Standards · Backoffice dApp
Difficulty: Medium → Hard
Track: Tokenization · Protocol + Product
Requires: Backoffice dApp, Escrow ID

---

Overview

This repository is a monorepo that contains:

• Multiple decentralized applications (dApps)
• Shared escrow Blocks as packages
• A Backoffice dApp that includes the Tokenize Escrow flow

In this task, contributors will:

1. Analyze and improve the token contract used when tokenizing an escrow
2. Improve the Backoffice UI so users can define token properties at creation time
3. Ensure the existing architecture—where the token sale contract holds minting rights—remains intact

This task focuses on making tokenized escrows first-class, standards-compliant assets.

---

Context: Tokenize Escrow Flow

When a user tokenizes an escrow in the Backoffice dApp:

• They must provide an Escrow ID

• The app deploys two contracts:

  1. A Token Contract
  2. A Token Sale Contract

• The Token Sale Contract is assigned minting rights on the token

This two-contract architecture is intentional and must not be broken.

---

Problem Statement

Today:

• Token metadata (name, ticker) is limited or hardcoded
• Users have little control over token identity
• Token contract compliance with current Soroban fungible token standards is unclear
• UI does not expose token properties clearly during creation

Desired:

• User-defined token properties
• On-chain, readable metadata
• Standards-aligned token contract
• Improved Backoffice UX during token creation

---

Goals

Product Goals

• Allow users to define at token creation:

  • Token name
  • Token symbol / ticker

• Associate the token clearly with the Escrow ID

• Make token identity explicit and understandable

---

Protocol Goals

• Ensure the token contract:

  • Implements the latest Soroban fungible token interface
  • Aligns with Stellar best practices
  • Is compatible with wallets and explorers

• Preserve the token sale → mint authority relationship

---

Non-Negotiable Constraints

🚨 Minting rights must remain with the Token Sale Contract

• The token contract:

  • Must not allow arbitrary minting
  • Must not give mint authority to the deployer

• Mint/admin rights must be:

  • Assigned at initialization
  • Delegated to the token sale contract

This is required for the tokenize escrow flow to work.

---

Scope of Work

1️⃣ Analyze the Existing Token Contract

• Review the current token contract implementation

• Identify:

  • How metadata is defined (or missing)
  • How admin / mint authority is assigned
  • Any deviations from Soroban standards

---

2️⃣ Standards Review (Required)

Compare the token contract against:

• Stellar Soroban Fungible Token interface
• Relevant SEP guidance (where applicable)
• OpenZeppelin-style Soroban patterns (if relevant)

Document:

• What is compliant
• What should be improved
• What should remain unchanged

---

3️⃣ Improve Token Contract Metadata

Update the token contract so:

• name and symbol:

  • Are provided at initialization
  • Are stored on-chain
  • Are accessible via standard methods

• Token metadata is:

  • Explicit
  • Explorer-friendly
  • Wallet-friendly

Optional (nice-to-have, if supported cleanly):

• Decimals
• Total supply visibility

---

4️⃣ Improve Backoffice Tokenize Escrow UI

In the Backoffice dApp:

• Enhance the Tokenize Escrow flow so users can:

  • Input token name
  • Input token ticker

• Ensure:

  • Escrow ID is required and clearly displayed
  • Token metadata reflects the escrow context

• Pass these values correctly to the token contract deployment

---

Escrow ID Requirement (Important)

To tokenize an escrow:

• An Escrow ID is required

• This ID should:

  • Be provided by the user
  • Be embedded into the token description or metadata (where appropriate)
  • Clearly link the token to the escrow it represents

---

API Requirements

• A Trustless Work API key may or may not be required

• Contributors should:

  • Use the Backoffice dApp as the primary surface
  • Document any API requirements encountered

---

Out of Scope

• ❌ Token sale contract changes
• ❌ Changes to escrow logic
• ❌ Indexers or analytics
• ❌ UI redesign beyond token creation inputs

---

Deliverables

• Improved token contract

• Improved Tokenize Escrow UI in Backoffice dApp

• Documentation or comments explaining:

  • Token metadata choices
  • Mint authority design

• Proof that:

  • Token sale contract still mints correctly
  • Tokenize escrow flow works end-to-end

---

Developer Workflow

• Create a new branch:

feature/improve-token-contract-and-ui

• Open a PR into main

• Include:

  • Explanation of contract changes
  • Screenshots of improved UI
  • Notes on standards compliance

---

Acceptance Criteria

• Users can define token name and ticker
• Token metadata is stored on-chain
• Token follows Soroban fungible token standards
• Token sale contract retains mint authority
• Tokenize escrow flow works without regression

---

Learning Outcomes

Contributors will learn:

• How tokenized escrows work in practice
• How Soroban fungible tokens are designed
• How multi-contract systems coordinate securely
• How UI and protocol design interact in Web3 products

---

Notes for Contributors

This task is cross-disciplinary:

• Part protocol
• Part product
• Part UX

Respect existing architecture.
Improve clarity, not complexity.

[drips-wave]

This issue has been added to the Stellar Wave Program and is worth 200 Points.

🧑‍💻 Interested in contributing? Apply to work on this issue on Drips Wave, earn points, and receive rewards.

🤠 Repo maintainers: You can manage this issue's Points and Complexity on your Maintainer Dashboard here. Please keep an eye on applications and respond quickly 💙

ℹ️ Learn more about Drips Wave

[big14way]

@big14way has applied to work on this issue as part of the Stellar Wave Program's 1st wave.

hi i am gwill i have contributed to stellar ecosystem and previously an od fellow i have experience in rust soroban
please assign me this issue its what i know how to do best

ℹ️ Repo Maintainers: To accept this application, review their application or assign @big14way to this issue.

[Arowolokehinde]

@Arowolokehinde has applied to work on this issue as part of the Stellar Wave Program's 1st wave.

Hi @techrebelgit
i am intrested in working on this issue
I have built, shipped, and contributed to projects using Soroban smart contracts, gaining hands-on experience writing efficient Rust programs and designing reliable test cases for real-world systems. I also recently contributed to the Rootstock ecosystem, working with both Solidity and Rust, which strengthened my understanding of cross-chain and blockchain-based architectures.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Arowolokehinde to this issue.

[pope-h]

@pope-h has applied to work on this issue as part of the Stellar Wave Program's 1st wave.

I’d like to apply for this issue.

I have experience with Soroban fungible token contracts, metadata design, mint authority delegation, and frontend dApp integration. I can improve the token contract for escrow tokenization, ensure standards compliance, and enhance the Backoffice UI without affecting existing token sale logic.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @pope-h to this issue.

[Lynndabel]

@Lynndabel has applied to work on this issue as part of the Stellar Wave Program's 1st wave.

Hi,

I will like to work on this issue.

I can analyze and improve the token contract to ensure it follows Soroban fungible token standards, stores metadata on-chain, and keeps mint authority with the Token Sale Contract. I can also enhance the Backoffice Tokenize Escrow UI so users can define token name, ticker, and associate the token with an Escrow ID, while maintaining the existing tokenize escrow flow end-to-end. I’ll document the changes, compliance with standards, and ensure no regressions.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Lynndabel to this issue.

[Villarley]

@Villarley has applied to work on this issue as part of the Stellar Wave Program's 1st wave.

Hey Alberto i'm Santiago Villarreal Full stack and smart contract dev in stellar ecosystem. would love to tackle on this one!

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Villarley to this issue.

[AlonsoFi]

@AlonsoFi has applied to work on this issue as part of the Stellar Wave Program's 1st wave.

Hi team,
I'm interested in taking on issue #24 (Improving the token contract + Tokenizing the escrow UI).
I have experience with Soroban and UI development in React/Next. I understand the restriction on maintaining mint rights in the token sale contract.
Can you assign it to me?

Thanks.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @AlonsoFi to this issue.

[Sandijigs]

@Sandijigs has applied to work on this issue as part of the Stellar Wave Program's 1st wave.

hi My name is Sandra.
I have reviewed the issue and understand what needs to be done
I am a fullstack software/ Blockchain Engineer with over 6years of experience web2 experience(Fullstack) and 2 year web3 experience (JavaScript,TypeScript, Rust ,Python, Soroban,Solidity,(Backend, frontend, Mobile and smart contracts) ). I have contributed to several projects in the stellar ecosystem. . please Assign this Issue to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Sandijigs to this issue.

[Bosun-Josh121]

@Bosun-Josh121 has applied to work on this issue as part of the Stellar Wave Program's 1st wave.

My background:
software engineering background, backend & smart contract dev
with robust experience in writing soroban contracts also returned contributor to the this project.
I have gone through the task and codebase with great understanding and I can take this.
I am confident in fulfilling the stated requirements and functions. Will work on feedback & recommendation ensuring contact. Can deliver within 48hrs upon assignment

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Bosun-Josh121 to this issue.

[drips-wave]

Congratulations, @Villarley! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on January 31, 2026.

🧑‍💻 @Villarley: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

⚠️ Important: When opening a PR, please link it to this issue to ensure it gets tracked accurately.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊