Token Mapping

This process involves a temporary hosting of BABEL-tokens on another blockchain that supports smart contracts, acting as a placeholder until the BABEL-chain is fully operational. Users initially acquire these temporary tokens, which they will later convert to the native tokens of the BABEL-chain. This mapping process is designed to be straightforward:

• Pre-Launch Phase: Users earn temporary BABEL-tokens on an existing smart-contract-enabled blockchain.
• Post-Launch Phase: Once the BABEL-chain is operational, a 1:1 token swap is initiated. Users will "burn" their temporary tokens, meaning they send these tokens to a blockchain “blackhole” address where they are permanently removed from circulation. In exchange, an equal number of BABEL-chain tokens are issued to the user's account on the new chain.

This mechanism ensures that the token supply remains consistent and that the value transfers seamlessly from one blockchain to another.

sequenceDiagram
participant blackhole (on another chain)
actor user
participant BABEL chain

user->>blackhole (on another chain): n temp-tokens
BABEL chain->>user : n native-tokens

Acceptance Contract

The acceptance contract serves as a bridge for users who wish to swap their BABEL tokens into USDC, a stablecoin pegged to the US dollar. This contract facilitates conversions at a predetermined exchange rate, providing stability and predictability for users. Key features include:

• Fixed Exchange Rate: This rate is set in advance, offering users clarity on the amount of USDC they will receive per BABEL token. It helps in budgeting and reduces the risk associated with price fluctuations.
• Daily Limit: There's a maximum cap on the total amount of BABEL tokens that can be converted into USDC each day. This daily limit helps manage liquidity and reduces the risk of large, sudden conversions that could destabilize the token's value.
• Interest: Users are incentivized to hold on to (not swap) BABEL.

sequenceDiagram
participant contract
actor user

user->>contract: n BABELs
contract->>user: r*n USDCs

Dev Bounty

In the developer community, a list of to-do modules (bounties) is publicly posted. Each developer team can bid on a module they want to work on, and they are rewarded with BABEL tokens upon completion.

To bid on a bounty, a developer team must submit a proposal detailing their plan for the task, along with the number of tokens they request as reward. The managing members review and vote on these proposals, considering the task's complexity, urgency, reward, and the proposed approach; bidding for a bounty is is basically like bidding for an auction, except more than money is considered. So, feel free to bid for a higher reward amount if your approach is magnificently better.

Once approved, the developers can start working.

After completion, the managing members review the completed work and assess its quality. If the work meets the set standards, the developers receive the agreed-upon number of BABEL tokens. If not, they receive constructive feedback and an opportunity to improve their work, or they can choose to accept a partial reward and relinquish the task. In this case, the task is reopened for other teams. The amount of partial reward takes into consideration the degree of fulfillment of the proposal and the difficulty for the next team to continue the work.

This system encourages a collaborative and competitive environment, promoting quality and innovation. All community members are welcome to join the review process.

graph TD
ch((choose a module))
sb(write proposal with reward)
r{review}
d(develop)
test{testing}
reward((reward))
p((partial\\nreward))
ch-->| |sb
sb-->| proposal |r
r-->|reject|ch
r-->|pass|d
d-->|deliver|test
test-->|pass|reward
test-->|feedback|re{continue?}
re-->|iterate|d
re-->|relinquish|p