Skip to content
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 20 additions & 10 deletions pages/developers/blueprints/manager.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -6,20 +6,30 @@ import ExpandableImage from '../../../components/ExpandableImage';

On Tangle, Blueprints have an offchain and an onchain lifecycle. The offchain component is managed by what we call the **Blueprint Manager**. The **Blueprint Manager** can be considered **_Tangle's Operator Node_**. This onchain and offchain logic functions as follows:

1. Operators must register for Blueprints onchain. This indicates an operators willingness to accept requests for Blueprint Instances of that type.
2. Operators upon registering for Blueprints onchain, download the Blueprint's binary and metadata from the Tangle Network. This is handled by the Blueprint Manager, which listens for new registrations.
3. Operators upon accepting Blueprint Instance requests, execute the Blueprint's binary. This is where the target environment of the Blueprint is important. The Blueprint Manager is responsible for executing the Blueprint's binary in the correct environment be it natively or in Docker or an alternative VM.
1. Operators must register for Blueprints onchain. This indicates an operator's willingness to accept requests for Service Instances of that Blueprint type.
2. Operators, upon registering for Blueprints onchain, download the Blueprint's binary and metadata from the Tangle Network. This is handled by the Blueprint Manager, which listens for new registrations.
3. Operators, upon accepting Service Instance requests, execute the Blueprint's binary. The Blueprint Manager is responsible for executing the Blueprint's binary in the correct environment, whether natively, in Docker, or an alternative VM.

### Blueprint and Service Instance Lifecycle

<ExpandableImage src="/images/ServiceInstanceFlow.png" alt="Service Instance Flow" />

Blueprints interact with the Tangle Network in several key ways:

1. Blueprints are deployed to Tangle, with their metadata and smart contracts stored and deployed on-chain.
2. Blueprints are instantiated, triggering the creation of an Instance, which represents a single AVS. The Instance runs for some period of time.
3. Blueprints are destroyed once they reach their time-to-live (TTL) or run out of funds to incentivize operators to run their service.

Blueprints provide a useful abstraction, allowing developers to create reusable service infrastructures as if they were smart contracts. This enables developers to monetize their work and align long-term incentives with the success of their creations, benefiting proportionally to their Blueprint's usage.

The Blueprint object is the core restaking object in Tangle, implemented primarily in the `pallet-services` module of the Tangle codebase. Assets are viewed as being restaked on Blueprints, with Operators running Instances of Blueprints and users restaking/staking their assets with those Operators.
1. **Blueprint Creation**: Blueprints are deployed to Tangle, with their metadata and configuration stored on-chain.
2. **Service Instantiation**: Users request Service Instances from Blueprints, which represent active services run by operators.
3. **Service Lifecycle**: Service Instances run until their time-to-live (TTL) expires or they are manually terminated.
4. **Payment and Incentives**: Service requestors provide payment to operators through the service request, supporting multiple asset types.

Blueprints provide a powerful abstraction for creating reusable service templates. This enables developers to:
- Define complex off-chain computation services
- Specify security requirements and operator constraints
- Configure job definitions and execution parameters
- Set up payment structures and incentive mechanisms

The Blueprint system is implemented in the `pallet-services` module of the Tangle codebase. Key features include:
- **Dynamic Membership**: Services can have fixed or dynamic operator sets
- **Job System**: Blueprints define callable jobs with specific arguments and permissions
- **Security Commitments**: Operators provide security deposits when joining services
- **Slashing Mechanisms**: Misbehaving operators can be slashed for violations
- **Quality of Service**: Heartbeat mechanisms and monitoring for service health
30 changes: 23 additions & 7 deletions pages/developers/precompiles/features/multi-asset-delegation.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -59,17 +59,17 @@ Below are example usages for some core methods on the multi-asset delegation int

1. Expand the `deposit(uint256 assetId, address tokenAddress, uint256 amount, uint8 lockMultiplier)` section.
2. Set `assetId` to `0` for ERC20 tokens, or provide another valid ID for other assets.
3. Provide the ERC20 contract address in `tokenAddress` if `assetId` is `0`. If using a native asset ID, this may be ignored depending on your setup.
3. Provide the ERC20 contract address in `tokenAddress` if `assetId` is `0`. For native assets, set this to the zero address.
4. Enter the `amount` you wish to deposit (in your asset's smallest unit, e.g., Wei for WETH).
5. Specify a `lockMultiplier` value if required by your delegation logic (`0` for no lock).
5. Specify a `lockMultiplier` value for lock duration rewards (`0` for no lock, higher values for increased rewards).
6. Click "transact" and confirm the MetaMask popup.

### 2. Schedule a Withdrawal

1. Expand `scheduleWithdraw(uint256 assetId, address tokenAddress, uint256 amount)`.
2. Fill in `assetId` (`0` for ERC20), `tokenAddress` (if `assetId` is `0`), and `amount`.
3. Click "transact" and approve the MetaMask transaction.
4. The withdrawal is now scheduled; you can later execute or cancel it.
4. The withdrawal enters an unbonding period; you can execute it after the period ends or cancel it anytime.

### 3. Execute a Scheduled Withdrawal

Expand All @@ -87,8 +87,9 @@ Below are example usages for some core methods on the multi-asset delegation int
### 5. Delegate to an Operator

1. Expand `delegate(bytes32 operator, uint256 assetId, address tokenAddress, uint256 amount, uint64[] memory blueprintSelection)`.
2. Enter the operator (as a bytes32 account id), the asset ID, token address if assetId is `0` (ERC20), the amount to delegate, and any required blueprint parameters.
3. Click "transact" to nominate that account as your operator with a specified stake.
2. Enter the operator (as a bytes32 account ID), the asset ID, token address if assetId is `0` (ERC20), the amount to delegate.
3. Provide `blueprintSelection` as an array of blueprint IDs the operator should participate in.
4. Click "transact" to delegate your assets to the operator.

### 6. Schedule Unstake for Delegators

Expand All @@ -112,8 +113,8 @@ Below are example usages for some core methods on the multi-asset delegation int
### 9. Check Overall Balance

1. Expand `balanceOf(address who, uint256 assetId, address tokenAddress)`.
2. Enter the address you want to inspect, assetId (0 for ERC20), and `tokenAddress` if needed.
3. Click "call" to see the total amount of assets held (deposited + delegated).
2. Enter the address you want to inspect, assetId (`0` for ERC20), and `tokenAddress` if needed.
3. Click "call" to see the total amount of assets held (deposited but not yet delegated).

### 10. Check Delegated Balance

Expand All @@ -123,6 +124,21 @@ Below are example usages for some core methods on the multi-asset delegation int

---

## Asset Types

- **Asset ID 0**: ERC20 tokens (requires token address)
- **Asset ID 1+**: Native or custom assets configured in the runtime

## Lock Multipliers

The `lockMultiplier` parameter in the deposit function allows users to lock their assets for longer periods in exchange for increased rewards:
- `0`: No lock (standard delegation)
- Higher values: Longer lock periods with proportionally higher reward multipliers

## Blueprint Selection

When delegating, the `blueprintSelection` parameter specifies which service blueprints the operator should run on your behalf. This enables targeted delegation to specific services or applications.

## More Information

For a complete list of methods and their parameters, refer to the Solidity interface above. This interface exposes all the critical multi-asset delegation functionality provided by Tangle's runtime, enabling you to manage deposits, schedule and execute withdrawals, delegate tokens, and unstake as needed—all through an Ethereum-compatible workflow. Make sure to handle asset IDs, token addresses, and amounts accurately to avoid transaction failures.
7 changes: 4 additions & 3 deletions pages/developers/precompiles/overview.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -84,6 +84,7 @@ The precompiled contracts are categorized by address and based on the origin net
| Schnorr-Ristretto255 | Verifies Schnorr signatures using the Ristretto255 curve. | `0x000000000000000000000000000000000000081f` |
| Schnorr-Taproot | Verifies Schnorr signatures using the Taproot Scheme. | `0x0000000000000000000000000000000000000820` |
| Bls12-381 | Performs operations on the BLS12-381 curve. | `0x0000000000000000000000000000000000000821` |
| MultiAsset Delegation | Provides functions for managing multi-asset delegation pallet. | `0x0000000000000000000000000000000000000822` |
| Services Pallet | Provides functions for managing services pallet. | `0x0000000000000000000000000000000000000823` |
| Liqued Staking | Provides functions for managing liquid staking pallet. | `0x0000000000000000000000000000000000000824` |
| Tangle LST | Provides functions for managing liquid staking pools. | `0x0000000000000000000000000000000000000809` |
| MultiAsset Delegation | Provides functions for managing multi-asset delegation. | `0x0000000000000000000000000000000000000822` |
| Credits | Provides functions for managing cloud credits system. | `0x0000000000000000000000000000000000000825` |
| Services | Provides functions for managing service blueprints and instances. | `0x0000000000000000000000000000000000000900` |
1 change: 1 addition & 0 deletions pages/restake/_meta.ts
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,7 @@ const meta: Meta = {
},
"restake-introduction": "Tangle Restaking",
incentives: "Incentives",
credits: "Tangle Credits",
how_to_restake: "How to Restake on Tangle",
restake_developers: "Developer Docs",
"-- liquid staking": {
Expand Down
9 changes: 9 additions & 0 deletions pages/restake/credits/_meta.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
import { Meta } from "nextra";

const meta: Meta = {
overview: "Overview",
claiming: "How to Claim Credits",
precompile: "Credits Precompile",
};

export default meta;
152 changes: 152 additions & 0 deletions pages/restake/credits/claiming.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,152 @@
---
title: How to Claim Credits
description: Step-by-step guide to claiming your earned Tangle Credits
---

# How to Claim Credits

This guide walks you through the process of claiming your earned Tangle Credits.

## Prerequisites

- Active TNT stake through the multi-asset delegation system
- Accumulated credits from staking or burning
- Off-chain account identifier for credit delivery

## Claiming via Tangle dApp

### Step 1: Check Available Credits

1. Navigate to the Credits section in the Tangle dApp
2. Connect your wallet
3. View your available credits balance
4. Check your credit accrual rate based on current stake

### Step 2: Initiate Claim

1. Click "Claim Credits"
2. Enter the amount of credits to claim
3. Provide your off-chain account ID
4. Review the transaction details

### Step 3: Confirm Transaction

1. Approve the transaction in your wallet
2. Wait for blockchain confirmation
3. Monitor the transaction status

### Step 4: Verify Credit Receipt

1. Check your off-chain account for credited amount
2. Credits should appear within minutes of confirmation
3. Contact support if credits don't appear within 24 hours

## Claiming via Polkadot.js

### Step 1: Navigate to Extrinsics

1. Open Polkadot.js Apps
2. Go to Developer > Extrinsics
3. Select your account

### Step 2: Submit Claim

1. Select `credits` pallet
2. Choose `claimCredits` extrinsic
3. Enter parameters:
- `amount`: Credits to claim
- `offchainAccountId`: Your off-chain identifier
4. Submit transaction

### Step 3: Monitor Events

1. Go to Network > Explorer
2. Find your transaction
3. Verify `CreditsClaimed` event emission

## Claiming via Command Line

Using the Tangle CLI:

```bash
tangle credits claim \
--amount 1000 \
--offchain-account "your-account-id" \
--account YOUR_ADDRESS
```

## Best Practices

### Optimal Claiming Frequency

- **Weekly claims**: Balance between gas costs and credit availability
- **Monthly claims**: Minimize transaction fees
- **Before unstaking**: Claim all available credits

### Maximizing Credit Accrual

1. **Maintain consistent stake**: Avoid frequent stake changes
2. **Choose appropriate tier**: Stake enough to reach efficient tiers
3. **Monitor tier changes**: Adjust stake when tiers update

### Security Considerations

- **Verify off-chain account**: Double-check account ID before claiming
- **Use secure connections**: Always use official dApps and tools
- **Keep records**: Track claims for accounting purposes

## Troubleshooting

### Credits Not Showing

If your credits aren't appearing:

1. **Check stake status**: Ensure your TNT is properly staked
2. **Verify time elapsed**: Credits accrue over time
3. **Review tier requirements**: Confirm you meet minimum stake

### Failed Claims

Common reasons for failed claims:

- **Insufficient credits**: Try claiming a smaller amount
- **Invalid account ID**: Verify off-chain account format
- **Network congestion**: Retry with higher gas fees

### Calculation Discrepancies

If calculated credits don't match expectations:

- **Check current tier**: Tiers may have been updated
- **Review stake changes**: Recent changes affect accrual
- **Consider time windows**: Accrual may be capped

## Technical Details

### Credit Calculation Formula

```
Credits = Staked_Amount × Rate_Per_Block × Blocks_Elapsed
```

Where:
- `Staked_Amount`: Your current TNT stake
- `Rate_Per_Block`: Tier-based emission rate
- `Blocks_Elapsed`: Blocks since last claim (capped)

### Event Structure

The `CreditsClaimed` event contains:
```rust
{
account: AccountId,
amount: Balance,
offchain_account_id: Vec<u8>
}
```

## Related Documentation

- [Credits Overview](/restake/credits/overview)
- [Credits Precompile](/restake/credits/precompile)
- [Staking Guide](/restake/how_to_restake)
Loading
Loading