OGIF office hours #41 ‑ ICY‑BTC swap, GitHub bot, MCP‑DB, Pocket Turing, Recapable, and arbitrage strategy

innnotruong
Mar 20, 2025

Topics and highlights

  • Swap ICY-BTC: Huy shared updates on the ICY-BTC swap mechanism, explaining the current state and adjustments needed to ensure accurate ICY valuation during swaps.
  • GitHub BotL: Thanh introduced a GitHub bot to automate PR reviews, aiming to improve processing speed and consistency in code management.
  • Memo UI: The team presented improvements to the Memo user interface, focusing on better data access and user experience.
  • Agentic: MCP-DB: Huy discussed the MCP-DB system, highlighting how it handles data storage and retrieval to support agents in automated workflows.
  • Pocket turning, Recapable: Vincent shared progress on the Pocket Turning and Recapable, outlining the completion of core gameplay and next steps.
  • Funding rate arbitrage: Antran presented a strategy for funding rate arbitrage across multiple exchanges, addressing technical challenges and execution strategies.

Vietnamese transcript

[05:30] Hôm nay chắc mình bắt đầu sớm nha. Buổi hôm nay chắc kết hợp với lại anh trong buổi meeting một xíu. Một phần là sẽ làm showcase, cái thứ hai là anh tổng kết một số việc mà bữa trước có trao đổi với mấy anh em á. Cái số hai, cái số ba là mình sẽ bắt đầu cho mấy anh em đăng ký công việc. Hiện tại để mà dễ trước, chắc là mình sẽ để cho Huy Nguyễn đi show mấy cái phần bên Huy trước, liên quan tới ICY một tí, xong rồi show một số cái về tech mà team mình đang làm nè. Để mình có một cái snapshot về chuyện là team tech thì hiện nay như thế nào nhé. Rồi sắp tới thì team mình cần gì, với lại mấy anh em xem contribute được gì vào đó ha.

[06:35] Huy, Thành đâu? Nhường sân khấu này nè. Rồi ok, nội dung đầu tiên, chắc là bên ICY Swap trước đi. Mình announce đó, hồi tuần trước, tuần này deploy lên rồi thì giờ những cái khác biệt như thế nào, chắc nhờ Huy đi lại hết mấy series đó.

[07:29] Alo, rồi rồi, đã xem màn hình rồi. Thì bây giờ mọi người có thể vào trang ICY Swap để mà swap được rồi. Đây, mình chỉ số liệu nha. Nhưng mà ở trên đây thì nó đang ready hết tất cả mọi thứ rồi. Việc làm duy nhất bây giờ là đang ngồi soát lại mấy cái số ICY á. Tại vì lúc trước vận hành á, thì mình vận hành theo kiểu là mình neo cái giá ICY, nên mình cũng không quan tâm cái lượng lưu thông (circulated) lắm. Nên có mấy trường hợp là mình để vô mấy cái ví của team, hoặc là chuyển qua mấy cái Mochi Balance của em hoặc là của anh Bảo. Thì mấy cái đó đang cần rà soát lại để mà nó ra cái số lưu thông đúng. Tại vì giờ mình sẽ ngồi, cái giá của mình nó sẽ dynamic theo cái pool nên cần ngồi check lại cái đó thì cũng gần xong hết rồi.

[09:09] Giờ còn mỗi cái account của anh Bảo là cần kiểm tra lại thôi. Nhớ có đợt là chuyển cho anh Bảo, giờ đang ngồi xem lại cái phần đó rồi cộng trừ lại rồi cắt cái phần đó ra khỏi cái circulated thì số này nó sẽ ra đúng. Còn lại hiện tại muốn swap ủng hộ thì cũng có thể swap được ở trên trang này. Lịch là đang vậy. Em show thử cái list Holder của mình hiện tại cho mấy anh em xem chắc cần biết nhiều hơn xíu. Trước giờ mọi người tham gia không quan tâm nhiều lắm nhưng mà chắc lần này thì mình cần để ý hơn.

[09:51] ICY của mình mình deploy ở trên Base, đúng không? Nên khi anh em vào trong cái list Holder, mọi người sẽ thấy được một cái list khoảng tất cả những cái ví nào đang được giữ ICY của team mình, thì là CCK Holder ha. Là một. Rồi thì cái link để mà vô đây chắc Huy share nha. Chứ mọi người lên mà search thì chắc không biết được đâu.

Đầu tiên là anh em cần nắm cái này. Quay qua đoạn này rồi. Anh nghĩ mấy anh em cần quan tâm phần này nhiều hơn xíu. Nó trở thành cái norm của thế giới tech luôn rồi, không cần làm gì mới nữa. Nên anh em nắm được thì sẽ ok hơn.

[10:33] ICY của mình hiện đã được list. Trong danh sách này có các ví minter, ví dùng để lập ngân sách cho các hoạt động, và một số ví đang nắm giữ lượng ICY lớn. Các hoạt động liên quan đến staking ICY sẽ được triển khai dần dần trong thời gian tới. Đây là thông tin đầu tiên anh em cần nắm rõ.

[11:15] Huy, demo thử luồng swap đi. Có ai có địa chỉ Bitcoin với một ít ICY không? Vincent có ở đây không? Ok, giờ thử swap từ ICY sang Bitcoin. Giá hiện tại được tính theo cơ chế động dựa trên lượng ICY đang lưu hành và pool. Chức năng swap rất đơn giản, chỉ cần điền số lượng, bấm swap là xong.

[12:27] Khoan đã, đừng nhập địa chỉ ảo. Ok, vậy là ổn rồi. Khung đầu tiên là ICY như bình thường. Ở dưới thì đang hiển thị đơn vị là satoshi, tức là đơn vị nhỏ nhất của Bitcoin. Khi nhập số lượng vào, nó sẽ tự động chuyển đổi. Tuy nhiên, tỷ giá hiện tại đang bị lệch một chút, khoảng 1.2 thay vì 1.5. Đây chắc là lỗi tính toán nhỏ, chỉnh lại là được.

[13:28] Cần có số ICY tối thiểu để swap. Thử nhập 30 ICY xem sao. Refresh lại thử xem có được không.

[14:43] Hình như không đủ tiền trong ví rồi. Bạn có ETH trên Base không? Chuyển qua Base và kiểm tra lại xem.

[15:51] Không phải lỗi đó đâu. Vấn đề là account chưa được đăng ký nên không thể thực hiện giao dịch. Sẽ fix phần đó sau. Mục tiêu ở đây là giúp mọi người hiểu rõ hơn về cơ chế swap và cách định giá token. Nếu nắm rõ thì sau này sẽ dễ dàng hơn trong việc quản lý tokenomics.

[16:47] Huy, giải thích nhanh lại cơ chế tính giá đi. Lần trước Quan demo chưa nói kỹ phần đó. Giá của ICY được xác định theo cơ chế minting, nghĩa là giá sẽ không thay đổi mạnh nếu có ai đó swap số lượng lớn. Nó không hoạt động theo kiểu cơ chế tạo lập thị trường tự động (AMM) mà giá sẽ được kiểm soát theo cơ chế minting. Cơ chế này giúp giá duy trì ổn định ngay cả khi có giao dịch lớn.

[17:43] Hoàn toàn là nó phụ thuộc vào Bitcoin. Nên nếu giá Bitcoin tăng thì lượng ICY mà anh em đang cầm sẽ tăng về giá trị USD. Còn về cơ chế minting, nhờ Huy giải thích thêm một chút. Nói chung là cơ chế chung của mình trước giờ là mình sẽ cố định giá trị của ICY theo USDC. Anh em không cần quan tâm nhiều, cứ hiểu đơn giản là một ICY tương đương với 1.5 USD.

**[18:37]**Phần đảm bảo này là để giúp team vận hành có thể đảm bảo là tới ngày thì sẽ đổi USDC vào trong contract để mọi người swap. Tỷ giá swap trong contract cũ là cố định ở mức 1.5 ICY, nhưng đó là model cũ. Model mới của mình thì linh hoạt hơn. Nếu anh em đã dùng Uniswap hay các AMM (Automatic Market Maker) khác thì nó cũng tương tự một chút. Ở đây, cơ chế hoạt động là bên dưới có một pool thanh khoản (liquidity pool), trong đó chứa cả ETH và USDC. Tùy vào tình hình của pool lúc đó, tỷ giá sẽ được điều chỉnh dựa trên lượng ETH và USDC trong pool.

[19:18] Cơ chế của mình cũng tương tự như vậy. Giá ICY sẽ được quyết định bởi lượng Bitcoin trong pool và lượng ICY đang được lưu hành. Công thức đơn giản thôi: mình có lượng ICY (X), có lượng BTC (Y) trong pool, thì X/Y sẽ ra được giá trị của một ICY tính theo BTC. Công thức này là công thức toán học cơ bản, không có gì phức tạp.

[19:55] Do cơ chế hoạt động của mình, sẽ có hai thời điểm làm thay đổi thanh khoản:

  1. Thời điểm đầu tiên là vào mỗi tháng, team vận hành sẽ đổ thêm BTC vào pool để làm chi phí cho các hoạt động của team. Lúc này giá ICY sẽ tăng lên một chút vì lượng BTC trong pool tăng lên.
  2. Thời điểm thứ hai là khi team đẩy thêm ICY vào pool (minting thêm). Khi mint thêm ICY, giá ICY trên thị trường sẽ giảm xuống do lượng ICY trong pool tăng lên.

[20:35] Hai trường hợp trên sẽ ảnh hưởng trực tiếp đến giá ICY. Còn nếu giá Bitcoin thay đổi thì giá trị USD của ICY có thể thay đổi, nhưng giá ICY tính theo BTC thì không thay đổi. Market impact từ Bitcoin là yếu tố bên ngoài, không ảnh hưởng trực tiếp đến việc minting hoặc giá trị ICY trong pool.

[21:12] Anh em có câu hỏi gì thêm thì đặt câu hỏi, tí nữa sẽ trả lời sau. À, có câu hỏi về việc swap ngược từ BTC về ICY đúng không? Hiện tại thì chưa có chức năng đó. Hiện tại chỉ hỗ trợ swap từ ICY sang BTC thôi, không có chức năng swap ngược lại. Tức là mua vào thì được, nhưng bán ra thì chưa hỗ trợ.

[21:40] Cảm ơn Huy. Có gì cần lưu ý thêm không? Cần lưu ý là hiện tại vẫn đang trong giai đoạn thử nghiệm nên có thể có một số trường hợp ngoại lệ. Ví dụ như một số tình huống có thể phát sinh khi swap hoặc thanh khoản chưa đủ. Về cơ bản thì luồng hiện tại vẫn đang hoạt động ổn định.

[22:00] Như là số lượng ICY tối thiểu để swap. Vì bản chất là team mình đang cover cái phần phí mà để mà làm gas trên ETH, trên Base và cả trên BTC luôn thì nên đang kiểu đang giới hạn cái số ICY nó swap nhiều tí để mà hạn chế với cái việc mà mọi người swap tầm 1-2 ICY để test á thì nó tốn cái chi phí gas nên đang để tầm trên 20 ICY mới cho mọi người swap trên web.

Cái thứ hai là ở cái do cái việc mà mình mint thêm ICY thì nó sẽ làm thay đổi giá thị trường, thì nên em đang disable luôn cái phần mà cơ chế cái ứng lương trước của mình.

[22:37] Tức là đồng loạt ứng lương thì nó sẽ ảnh hưởng giá đúng không? Vậy cái lesson learn trong cái này đó là sau đợt này làm thì có vài điểm mà anh đang thấy là bắt đầu team mình đang tập trung vô build những cái tool nó hỗ trợ mình hoạt động. Cũng là một số cái thử nghiệm mới, cũng là một số cái mà hỗ trợ hoạt động thiệt sự. Nhưng mà sau khi xong mấy cái bài này thì nó sẽ ra được một số mấy cái article liên quan thì mấy anh em nếu mà trước đó không có tham gia những cái dự án đó có thể tìm lại những cái bài đó để mà coi được cái game, cái knowledge game từ cái đợt đó là cái gì của mấy anh em làm dự án đó ha.

[23:24] Rồi thì trong cái vụ ICY Swap đợt này chắc là được hai ba bài phải không? Dạ, như được ba bài. Còn kiểu viết nhiều thêm thì vẫn có nhiều cái để viết. Ừ, thôi đó cứ thong thả từ từ đi.

[24:02] Sau phần của Huy, anh cảm ơn Huy rồi chuyển sang nội dung thứ hai liên quan đến những gì team mình đang làm. Anh Bảo ai nói trước cũng được, nhưng chắc là để Thành nói trước. Thành bảo là em nói trước cũng được, em sẽ gom lại hết để anh cho mọi người biết team đang ở giai đoạn nào. Nhưng anh bảo là để Thành nói trước đi, tại vì đang có người bấm chuông. Rồi anh mời Thành bắt đầu.

[25:00] Mọi người, Memo của mình là một trong những cái đợt lớn đợt này, có upgrade format lại cho nhìn nó ok hơn tí. Mình luôn muốn mình tạo những cái map content, những cái thứ mà mình đọc được cái mình up lên đây. Nhưng mà hiện tại cái mô hình đó thật ra nó cũng không có còn quá hiệu quả với chuyện là mấy cái model ra đời nó nén dữ liệu lại, rồi mình query trực tiếp từ đó ra thì nó sẽ hiệu quả hơn.

Thì cái point của chuyện là đưa những cái kiến thức mà nó bình thường lên trên Memo thì nó cũng không phù hợp lắm ha. Nên đợt này lúc mà làm lại thì có một cái ý chính để mà muốn nói với anh em đó là Memo hiện tại sẽ được dùng chỉ cho mục đích duy nhất thôi , đó là cái knowledge gain mà từ dự án.

Cái đó là gần như là những cái mới mà nó xuất phát từ chính cái hoạt động của cái team mình. Gần như trên đây sau này nó sẽ gồm là liên quan tới lĩnh vực gì đó, mình đã làm gì đó trong đó. Nó có nhiều hơn, maybe là sau một giai đoạn thì khi tụi nó train lại cái model thì những cái dữ liệu của mình á thì nó sẽ trở thành một phần của kiến thức chung cho cả cộng đồng.

[25:39] Và cái phần này anh nghĩ là nó sẽ giúp ích rất nhiều cho cái chuyện mà mọi người làm kiểu training lại cho AI model sau này, hoặc là mấy cái chuyện mà mình muốn nó có cái việc mà suggestion kiểu tự động ấy.

[26:24] Nội dung sẽ trở thành một phần trong mô hình đó hoặc nếu có mấy công cụ tìm kiếm trên internet, thì có thể bài của mình chỉ là một phần nhỏ trong nguồn tài liệu được tham khảo vào thôi, giống như là một phần nhỏ trong citation. Điều này cũng không có vấn đề gì lớn. Nhưng nhìn chung, toàn bộ những nội dung này sẽ gần như trở thành spirit của team.

Trong lần nâng cấp lớn này, có một điểm chính mà Tuấn đã hoàn thành chưa nhỉ? Tuấn ơi, phần liên quan đến việc đồng bộ toàn bộ dữ liệu của team, nhất là về phần nội dung, hiện đang được định hướng như vậy để các thành viên nắm rõ hơn.

[27:00] Tức là sau đợt này, các thành viên đang tham gia vào các dự án sẽ có xu hướng ngồi lại với nhau để xem xét kỹ hơn từ những dự án đó, và xác định rõ phần knowledge gain (kiến thức thu được) từ chính các dự án đó là gì. Sau đó, team sẽ đưa lên Memo làm nguồn tài liệu nội bộ cho team.

Phần thứ hai là ở cuối mỗi bài sẽ có một phần liên quan đến group of reading. Hiện tại phần này vẫn chưa hoàn chỉnh, nhưng ý tưởng là sau khi hoàn thiện, sẽ có thêm phần thông tin tổng hợp về bài viết để người đọc có thể tra cứu và học thêm từ bài viết đó.

[27:47] Ngoài ra, tất cả dữ liệu của team được viết ra sẽ được gán định danh ví dụ như GitHub, Discord, hoặc những kênh nội bộ khác. Dữ liệu này sẽ được upload lên dạng blockchain storage trên nền tảng Arweave (AV) – một nền tảng lưu trữ phi tập trung. Điều này giúp cho nội dung của team có một định danh rõ ràng và minh bạch.

Thêm vào đó, người đọc sẽ có thể xem lại bài viết, đánh giá hoặc để lại phản hồi trực tiếp trên bài viết. Đây là một phần của ý tưởng nâng cấp mới cho trang Memo của team.

[28:39] Trước đây, team đã có ý định sử dụng Obsidian để quản lý nội dung, nhưng có vẻ như một số thành viên gặp khó khăn trong việc làm quen với công cụ đó. Vì vậy, hiện tại để làm cho mọi thứ đơn giản hơn, team sẽ chuyển sang cơ chế trực tiếp hơn. Cụ thể là thay vì phải làm qua Obsidian, các thành viên có thể submit nội dung trực tiếp vào repository của thư viện chung của team.

Các thành viên chỉ cần đưa nội dung vào và submit trực tiếp qua nền tảng này, không cần phải tuân theo workflow bắt buộc của Obsidian nữa. Nếu ai vẫn muốn dùng Obsidian thì không sao, nhưng nếu không dùng thì cũng không ảnh hưởng gì cả. Đây là thay đổi cơ bản nhất trong hệ thống Memo của team.

[29:24] Hiện tại team đang làm một số dự án chính, bao gồm:

  1. Bitcoin Swap – đã nhắc tới ở phần trước.
  2. Memo – vừa mới trình bày xong.
  3. Hai dự án nhỏ khác:
  • agentic – nhóm của Quang và Huy đang phát triển.
  • github bot – nhóm của Thành đang thực hiện, hiện đang test thử.

Giờ chắc nhường lại cho Thành để chia sẻ thêm về những nội dung này.

[30:32] Dự án này đã được khởi động hơn một tuần và đã chính thức chạy code được hơn một tuần. Mục đích chính của nó là tạo ra một hệ thống nhắc nhở (reminder). Trước đây, team thường gặp tình huống khi tạo pull request (PR), mọi người hay để đó và chờ chạy xong rồi quên luôn việc cần review. Tool này sẽ phục vụ cho việc theo dõi và cập nhật thông tin về các hoạt động hàng ngày trên github hoặc hàng tuần trên các kênh giao tiếp nội bộ của team.

[31:18] Hệ thống này được thiết kế dưới dạng một tích hợp đơn giản. Luồng hoạt động cơ bản bao gồm một số use case như: thông báo cho người được assign để review, tương tác với GitHub API, và post thông tin vào các kênh nội bộ như Discord hoặc Slack. Hiện tại, team đang test thử trên Discord. Ngoài ra, team cũng đang thử nghiệm với agentic và một framework mới gọi là Mastra AI.

Framework này khác với các tool Python thông thường. Một số thành viên trong team không quen làm việc với Python, nên team muốn thử nghiệm xem liệu sử dụng framework mới này có hiệu quả hơn các giải pháp hiện tại hay không. Framework này hỗ trợ các tính năng như setup môi trường, define các trạng thái để quản lý dữ liệu, và cho phép cấu hình lại tùy theo nhu cầu của team.

[32:19] Cấu trúc của hệ thống này có hai phần chính:

  1. Agentic app – Đây là ứng dụng chính để xử lý các hoạt động của hệ thống.
  2. Discord app – Hỗ trợ việc gửi thông báo vào Discord.

Ngoài ra, hệ thống còn có một vài component phụ, như workflow để xử lý công việc theo lịch trình, kiểm tra và thông báo cho developer nếu có bất kỳ pull request nào đang chờ được review. Nếu pull request vượt quá một khoảng thời gian nhất định, hệ thống sẽ gửi thông báo để nhắc người thực hiện review.

[33:12] Agentic app sẽ expose một vài API cho phép chat và theo dõi trạng thái của các pull request. Khi có một pull request được tạo ra, hệ thống sẽ tự động xác định các điều kiện như trạng thái của pull request (work in progress hay chưa), thời gian tạo pull request, và sẽ gửi thông báo cho người review sau khoảng 30 phút kể từ lúc tạo. Ví dụ: nếu có một pull request cần được review nhưng không có ai assigned hoặc đã quá thời gian xử lý, hệ thống sẽ tự động ping lại người phụ trách.

[35:02] Thay vì phải theo dõi thủ công, hệ thống sẽ gắn con agent vào để tự động theo dõi và thông báo thông qua endpoint của hệ thống. Trong phần logic, hệ thống sẽ định nghĩa các điều kiện cụ thể, chẳng hạn như chỉ gửi thông báo nếu pull request được tạo trong vòng 30 phút hoặc đang trong trạng thái work in progress. Nếu pull request được cập nhật hoặc chuyển trạng thái, hệ thống sẽ tự động theo dõi và gửi thông báo cho developer để đảm bảo không bị sót.

[35:39] Hệ thống sẽ hoạt động dựa trên code filter thông thường. Ngoài ra, nó sẽ có một số workflow khác như việc gửi thông báo vào cuối ngày để tổng hợp tình trạng của các pull request trên Discord. Hệ thống sẽ tự động gửi thông báo về số lượng pull request đang mở, tình trạng của chúng và trạng thái review hiện tại. Đây là chức năng chính của tool này , đóng vai trò như một công cụ reminder.

[36:24] Hệ thống cũng có thể tích hợp với các công cụ chat khác. Đơn giản là có thể tạo thêm một command và gửi request tới endpoint của hệ thống. Các request này sẽ được định nghĩa dựa trên schema cụ thể, ví dụ như input là review ID hoặc các thông tin khác liên quan đến trạng thái của pull request. Hệ thống sẽ lấy dữ liệu này và hiển thị trên giao diện mà người dùng thường xuyên sử dụng.

[37:04] Phần xử lý backend của hệ thống được thực hiện thông qua tool Lippia, một công cụ định dạng dữ liệu JSON thành dạng bảng Markdown table hoặc dạng data binding. Hiện tại team đang test thử hai luồng xử lý này trước khi mở rộng thêm các tính năng khác. Khi hệ thống hoạt động ổn định, các workflow này sẽ được mở cho tất cả các thành viên trong team thử nghiệm và phát triển thêm.

[38:08] Hệ thống được thiết kế để mở rộng một cách linh hoạt. Các thành viên trong team có thể tự phát triển và đóng góp các workflow khác nhau. Hệ thống này cho phép xây dựng các tool dưới dạng một đơn vị độc lập (packaging unit), sau đó kết hợp các đơn vị này lại để tạo ra các workflow phức tạp hơn. Khi muốn phát hành một workflow mới, các thành viên chỉ cần định nghĩa lại đơn vị cơ bản và tích hợp nó vào hệ thống.

Việc mở rộng các workflow sẽ giúp hệ thống phát triển theo chiều ngang (mở rộng số lượng tính năng), thay vì theo chiều dọc (phát triển tính năng hiện tại). Khi số lượng các workflow tăng lên, hệ thống sẽ càng trở nên linh hoạt và mạnh mẽ hơn.

[38:54] Về cơ bản, workflow được coi là lớp ứng dụng (application layer) tương tự như các API data trước đây. Hệ thống này sẽ hoạt động ở cấp độ tool, nhưng người dùng cuối sẽ tương tác với nó qua giao diện của workflow. Hiện tại, vẫn chưa có đơn vị nào triển khai thành công mô hình này ở quy mô lớn. Tuy nhiên, GitHub hiện đã mở rộng API cho các developer tạo các extension và tích hợp chúng trực tiếp vào GitHub.

[39:40] Dify đang xây dựng một nền tảng để hỗ trợ các developer phát triển và triển khai các tool và workflow này một cách dễ dàng hơn. Mục tiêu là tạo ra một marketplace để các tool và workflow có thể được phân phối và sử dụng bởi nhiều người dùng khác nhau. Hệ thống này tương tự như một nền tảng mở, cho phép các developer bên thứ ba triển khai các tool và workflow của riêng họ.

Trên nền tảng của Dify đã có khoảng 50 tool khác nhau. Một số tool đã từng được phát hành dưới dạng thử nghiệm, nhưng do chưa có định hướng rõ ràng và thiếu sự hỗ trợ từ cộng đồng, nên chúng chưa đạt được thành công như mong đợi.

[40:17] Một số nền tảng trước đây đã thử xây dựng mô hình tương tự nhưng chưa đạt được thành công. Lý do là vì các tool này chỉ được xây dựng dưới dạng form, thiếu khả năng tương tác với dữ liệu bên ngoài và chưa có khả năng kết hợp các workflow phức tạp. Tuy nhiên, Dify đang tập trung vào việc giải quyết các vấn đề này để tạo ra một hệ sinh thái hoàn chỉnh cho các workflow và tool.

[40:59] Các công cụ này cũng cho phép người dùng đẩy dữ liệu từ các nguồn bên ngoài vào hệ thống. Người dùng có thể gửi dữ liệu từ các ứng dụng bên ngoài qua các Open Form hoặc API. Dify sẽ tự động xử lý và định dạng dữ liệu để sử dụng trong các workflow của hệ thống.

[41:56] Team đang tập trung vào hai hướng phát triển chính:

  1. Tiếp tục mở rộng và phát triển các workflow hiện có.
  2. Cải tiến và tối ưu hóa các công cụ hiện tại để hỗ trợ việc triển khai và sử dụng dễ dàng hơn.

Hệ thống được xây dựng dựa trên các tiêu chuẩn chung về thiết kế tool và workflow. Công cụ Smithery hiện tại đang đóng vai trò như một Agent để quản lý các workflow. Smithery cũng có thể được sử dụng như một Package Manager để cài đặt và quản lý các tool trong hệ thống.

[42:53] Workflow sẽ hoạt động theo cơ chế, nếu một workflow nào đó trở nên phổ biến, mọi người có thể lấy nó về và sử dụng dưới dạng tool. Bản chất của các công cụ này là được thiết kế để phục vụ các domain cụ thể. Ví dụ như một công cụ để tạo file, tìm kiếm hoặc lấy file code chẳng hạn. Nó hoạt động giống như một SDK, tức là một bộ thư viện mà bạn chỉ cần import vào để sử dụng.

[43:37] Khi đã tích hợp vào SDK, bạn có thể sử dụng các method sẵn có để thao tác với dữ liệu. Điều này cho phép tích hợp dễ dàng vào các công cụ AI. Hiện tại, chỉ có Cross là hỗ trợ trực tiếp cho các thao tác này. Tuy nhiên, trong tương lai, nó sẽ được chuẩn hóa để các công cụ khác cũng có thể dễ dàng tích hợp. Trường hợp của Manus là một ví dụ. Manus sử dụng rất nhiều tool khác nhau, tuy nhiên khi so sánh với hệ thống agent trong Smithery, về cơ bản chúng là hai lớp hoàn toàn khác nhau.

[44:15] Trong hệ thống của Manus, các công cụ được kết hợp lại để tạo ra các workflow tổng quát hơn. Các công cụ này hoạt động ở các lớp khác nhau, trong khi các agent trong Smithery được thiết kế để hoạt động độc lập. Câu hỏi đặt ra là làm thế nào để phân biệt rõ ràng sự khác nhau giữa hệ thống của Manus và hệ thống agent trong Smithery. Có một bài tóm tắt về điều này đã được đăng trong kênh AI Club , nội dung chính nói về khả năng suy nghĩ (thinking) và khả năng sử dụng máy tính (computer use).

[45:09] Cơ chế của hệ thống Manus là một hệ thống service-oriented. Để kết hợp nhiều tool với nhau trong cùng một workflow, cần phải định nghĩa rõ các bước thực hiện. Ví dụ như bước 1 cần sử dụng tool nào, bước 2 cần sử dụng tool nào, v.v. Điều này đòi hỏi các bước phải được cấu hình cụ thể. Tuy nhiên, hệ thống mới có khả năng suy luận để tự động xác định xem cần sử dụng những công cụ nào để hoàn thành tác vụ. Đây chính là điểm khác biệt giữa hệ thống mới và các hệ thống cũ.

[45:59] Cụ thể, hệ thống mới có thể nhận biết được một tác vụ cần sử dụng bao nhiêu công cụ, thực hiện qua các bước nào, và có thể điều chỉnh thứ tự thực hiện một cách thông minh. Đây là một cơ chế đặc biệt và khác biệt so với các hệ thống cũ. Nói cách khác, nó hoạt động như một Supervisor , có khả năng suy luận và đưa ra quyết định về thứ tự và phương pháp thực hiện các bước trong workflow.

[46:35] Hệ thống Supervisor hoạt động ở lớp cao hơn so với các agent trong Smithery. Các agent trong Smithery chỉ đơn giản là các công cụ thực thi một tác vụ cụ thể, trong khi Supervisor có khả năng quản lý và điều phối toàn bộ quá trình thực hiện tác vụ. Việc tích hợp Supervisor cho phép hệ thống hoạt động một cách linh hoạt hơn, đồng thời dễ dàng mở rộng và bổ sung thêm các công cụ mới.

[47:33] Mục tiêu của team là hiểu rõ cách hoạt động của hệ thống và nắm được cơ chế điều hành của các workflow. Nếu có thể xác định được cách thức triển khai và quản lý các workflow, thì sẽ có thể chọn lọc và sử dụng các công cụ hiệu quả hơn. Đây là điều mà team đang hướng tới , xây dựng một hệ thống có khả năng mở rộng và tối ưu hóa quy trình làm việc.

[48:24] Tiếp theo, team sẽ tập trung vào việc xây dựng hệ thống MCP. Đây là một hệ thống mới được thiết kế để quản lý dữ liệu và workflow. Team đã tiến hành demo hệ thống này cách đây khoảng hai tuần. Bản chất của hệ thống MCP là xây dựng một agent hoạt động trên nền tảng có sẵn. Người dùng có thể nhanh chóng triển khai và kiểm tra hệ thống thông qua MCP.

[49:10] MCP sẽ là một hệ thống hoàn chỉnh, bao gồm một cơ sở dữ liệu (database) và một máy chủ (server). Điều này cho phép hệ thống hoạt động một cách độc lập và có khả năng xử lý dữ liệu lớn. Khác với các hệ thống cũ, MCP sẽ cho phép người dùng điều chỉnh cấu hình và quản lý dữ liệu dễ dàng hơn.

[49:58] Bản chất của MCP là một agent, được định nghĩa theo một cấu trúc input và output cụ thể. Điều này cho phép các hệ thống khác nhau có thể kết nối và tương tác với MCP thông qua các giao thức tiêu chuẩn. Nói cách khác, MCP có thể được tích hợp vào bất kỳ hệ thống nào thông qua các giao thức được định nghĩa sẵn.

[50:35] MCP cũng cho phép người dùng quản lý dữ liệu thông qua Knowledge Database, bản chất nó là timescale database, dump hết mọi data về hoạt động của team vào trong đó. Đây là một cơ sở dữ liệu dạng time-series, cho phép ghi nhận các sự kiện theo thời gian thực, ai làm backend sẽ quen dạng event sourcing, event log. Ví dụ: ghi nhận thông tin về các thành viên của team, trạng thái hoạt động của hệ thống, hoặc các sự kiện quan trọng khác.

[51:13] Knowledge Database sẽ lưu trữ toàn bộ dữ liệu hoạt động của team, bao gồm các thông tin như ai đã thực hiện tác vụ gì, trạng thái của hệ thống vào từng thời điểm cụ thể, và các thông tin khác liên quan đến hoạt động nội bộ của team. Điều này cho phép team theo dõi và phân tích hiệu suất làm việc, từ đó đưa ra các quyết định điều chỉnh hợp lý.

[51:51] Concept của hệ thống sẽ có một thành phần gọi là Landing Zone. Landing Zone có nghĩa là mọi dữ liệu mà mình đang có , khoảng mười mấy đến hàng chục bộ dữ liệu (database) , sẽ được tập kết vào đây. Trước đây, khoảng ba đến năm năm trước, nếu muốn xây dựng một hệ thống lưu trữ dữ liệu mình sẽ tạo một con bot để thu thập mọi hoạt động của team và đưa vào trong cơ sở dữ liệu của mình.

Với mô hình Meta mới, tất cả các dữ liệu lớn (Big Data) sẽ được dump vào một kho lưu trữ tạm thời dưới dạng file .dat trên S3 hoặc GCS (Google Cloud Storage). Con MCP này sẽ có khả năng đọc trực tiếp từ Landing Zone. Nếu hệ thống thấy rằng dữ liệu trong Landing Zone có giá trị và cần thiết, nó có thể tự động chuyển đổi dữ liệu đó sang dạng Time Series Database (TSDB) để sử dụng lâu dài. Đây chính là end game (kết quả cuối cùng) của hệ thống này.

Còn lại, vấn đề sẽ là xây dựng các Use Case (trường hợp sử dụng) dựa trên các dữ liệu đã được tổ chức trong hệ thống , theo hướng mà team mong muốn. Đây là định hướng phát triển quan trọng của hệ thống MCP trong thời gian tới.

[52:25] Vậy là hiện tại team sẽ có một hệ thống cơ sở dữ liệu cũ , đó là cơ sở dữ liệu dạng table kiểu cũ, nằm ở phần bên dưới của hệ thống (có thể thấy trên diagram với các khối màu xanh dương). Giờ đây, team đang bổ sung thêm hai thành phần mới:

  • Thành phần Landing Zone , nằm trong khối màu vàng phía trên của hệ thống.
  • Thành phần Time Series Database (TSDB) , được kết nối trực tiếp với các thành phần trong hệ thống cũ để phân tích và khai thác dữ liệu.

Team đang lưu trữ các dữ liệu thô trong Landing Zone. Về bản chất, việc tập kết dữ liệu trong Landing Zone giống như việc gom quân , tập trung tất cả dữ liệu về một chỗ, sau đó mới quyết định cách phân tích và xử lý. Đây là cơ chế giúp hệ thống vận hành linh hoạt hơn và dễ dàng mở rộng khi có thêm dữ liệu mới.

[53:11] Điểm đặc biệt của hệ thống này là khả năng tự động chuyển đổi dữ liệu từ Landing Zone sang Time Series Database. Cơ chế này xuất phát từ nhu cầu ngày càng tăng về phân tích dữ liệu cục bộ (local analytics). Đây là xu hướng đang nổi lên trong bối cảnh sự phát triển của AI (Trí tuệ nhân tạo).

Sự trỗi dậy của AI đã làm gia tăng nhu cầu về các hệ thống phân tích dữ liệu theo thời gian thực. Khi các dữ liệu thô được tập kết vào Landing Zone, hệ thống sẽ tự động nhận diện dữ liệu có giá trị và chuyển chúng sang TSDB để phân tích chi tiết hơn. Đây là một bước tiến quan trọng trong việc xây dựng hệ thống phân tích dữ liệu hiệu quả và có khả năng thích ứng với những thay đổi của thị trường.

[53:45] Hiện tại team đã có thể chạy analytic trực tiếp cho phần dữ liệu được lưu trữ trên local. Hệ thống này cho phép chạy analytic ngay trên dữ liệu Data Lake mà không cần phải chuyển dữ liệu đi xa. Đối với phần dữ liệu trong Landing Zone , tức là phần file packet mà Huy đang show trên màn hình , đây là phần mà team cần tập trung nghiên cứu thêm. Vấn đề này có liên quan đến text processing, nên mấy anh em cần phải pick up (nắm bắt) chủ đề này. Cái này cũng không khó lắm, chắc học trong vòng nửa ngày là có thể nắm được cơ bản.

Phần Prompt để tìm kiếm và khai thác dữ liệu cũng khá nhanh và đơn giản, không phức tạp. Đây là phần rất đáng để thử nghiệm vì nó liên quan đến cơ chế knowledge discovery (khám phá tri thức) trong hệ thống. Đây là một trong những phần nâng cấp mới mà Huy vừa nhắc tới.

[54:22] Điểm nổi bật nhất của hệ thống trong đợt nâng cấp này chính là Knowledge Hub. Đây là nơi mà team sẽ tập trung toàn bộ dữ liệu để phục vụ cho việc phân tích và khai thác tri thức. Knowledge Hub sẽ trở thành một dạng data pool chung của toàn team. Bất kỳ ai cũng có thể thêm dữ liệu vào đây, và hệ thống sẽ xử lý, chuyển đổi dữ liệu theo format tiêu chuẩn.

Điều quan trọng là khi hệ thống đã được thiết lập xong, mọi người trong team sẽ có chung một protocol để sử dụng. Các module hoặc component khác nhau sẽ có thể share (chia sẻ) chung một cấu trúc dữ liệu và truy cập trực tiếp vào Knowledge Hub. Đây sẽ là nền tảng chung để đồng bộ dữ liệu và xử lý dữ liệu trong nội bộ team.

[54:58] Về phần cơ sở dữ liệu (DB), hệ thống sẽ có hai lớp:

  • DB cũ: Dùng để hỗ trợ các nghiệp vụ hiện có và xử lý các dữ liệu có cấu trúc sẵn.
  • DB mới: Được thiết kế để kết nối trực tiếp với Knowledge Hub và hỗ trợ phân tích dữ liệu theo thời gian thực.

Điểm đặc biệt là phần MCP sẽ đóng vai trò như một protocol để các module khác nhau có thể giao tiếp với nhau. Điều này có nghĩa là bất kỳ dữ liệu nào cần được truy cập hoặc xử lý, chỉ cần đưa vào đúng đường dẫn của hệ thống thì nó sẽ tự động được xử lý theo cấu trúc tiêu chuẩn. Đây là cách để hệ thống đồng nhất dữ liệu và tránh xung đột khi có nhiều nguồn dữ liệu cùng được xử lý.

[55:43] Từ giờ, team sẽ cần làm quen với các cơ chế xử lý dữ liệu mới. Mọi người nên dành thời gian để tìm hiểu thêm về các thành phần trong hệ thống mới. Khi các thành phần này hoạt động ổn định, các dự án mới của team sẽ tận dụng các công cụ này để triển khai nhanh hơn và hiệu quả hơn. Đây sẽ là bộ công cụ chính để phục vụ cho các dự án trong tương lai.

Hệ thống này có tiềm năng trở thành requirement bắt buộc trong các dự án tiếp theo. Nếu bạn muốn bắt kịp với hệ thống mới, hãy bắt đầu từ việc tìm hiểu các nguyên lý cơ bản về MCB và các protocol liên quan.

[56:40] Trước đây, khi team triển khai hệ thống trên S3 hoặc GCS (Google Cloud Storage), việc xử lý dữ liệu khá mất thời gian. Tuy nhiên, với cơ chế mới, dữ liệu từ Landing Zone sẽ được xử lý nhanh hơn và dễ dàng hơn.

Hệ thống đã được thử nghiệm trên nhiều nền tảng khác nhau, bao gồm S3 và GCS. Tuy nhiên, vì hạ tầng hiện tại của team đang chạy trên GCS, nên các dữ liệu từ Landing Zone sẽ được xử lý trên GCS trước. Mặc dù vậy, về mặt kỹ thuật, hệ thống này có thể mở rộng sang các nền tảng khác mà không gặp trở ngại lớn.

[57:45] Cơ chế hoạt động của Landing Zone khá đơn giản:

  • Các dữ liệu từ nhiều nguồn khác nhau sẽ được tập trung vào Landing Zone.
  • Các dữ liệu này sẽ được lưu dưới dạng file Parquet theo từng ngày.
  • Hệ thống có khả năng đọc lại các file này thông qua cơ chế Time Series Database (TSDB).

Hiện tại, một số file Parquet mẫu đã được tạo và đang trong quá trình kiểm tra. Nếu cần, team có thể chạy thử demo trên các dữ liệu mẫu này để kiểm tra tính nhất quán của hệ thống.

[58:24] Những hoạt động của team giống như kiểu AI sub hoặc Memo thì nó cũng được đẩy hết lên đây. Nhiệm vụ của Landing Zone là lưu trữ mọi dữ liệu mà team muốn, ai muốn lưu trữ gì thì cứ đẩy hết vào đây rồi sau đó hệ thống sẽ quyết định xử lý dữ liệu đó như thế nào. Hệ thống cũng đã cung cấp một số công cụ để mọi người có thể đẩy dữ liệu lên, ví dụ như là các API proxy để forward các sự kiện. Mọi người muốn push thông tin lên Landing Zone thì chỉ cần gọi API là được.

Memo hiện tại đang sử dụng cơ chế này để lấy dữ liệu từ các nền tảng xã hội và đồng bộ vào hệ thống. Cơ chế này cũng đã được thử nghiệm thành công. Còn đối với những loại dữ liệu có tính đặc thù như là Discord messages hoặc data từ Basecamp, team cần phải xây dựng các crawler hoặc các connector để thu thập dữ liệu. Hiện tại, team đã có một số template sẵn cho những loại dữ liệu này.

[58:59] Về hướng phát triển tiếp theo, team sẽ tập trung vào việc khai thác dữ liệu từ Landing Zone. Nếu bạn muốn tham gia vào dự án này, lời khuyên là hãy bắt đầu từ một vertical cụ thể. Ví dụ:

  • Xác định một use case rõ ràng.
  • Tìm hiểu xem dữ liệu nào cần cho use case đó.
  • Định nghĩa lại cơ chế khai thác dữ liệu theo hướng từ trên xuống dưới.

Thay vì kiểu thấy dữ liệu nào hay thì lưu lại, team nên nghĩ theo hướng là xác định use case trước rồi mới quyết định lưu trữ dữ liệu. Điều này giúp hệ thống hoạt động một cách có tổ chức và dễ dàng quản lý hơn.

Ví dụ cụ thể là nếu có một use case về Project Nghệ Nhân thì team sẽ cần tạo một Git Agent để thu thập dữ liệu từ Git, sau đó đẩy dữ liệu đó vào Knowledge Hub thông qua MCP. Từ đó, hệ thống sẽ định nghĩa các công cụ khai thác dữ liệu cho use case này.

[1:00:16] Ngoài ra, team đang phát triển một MCP Server nhỏ. MCP Server này thực chất là một server cơ bản, sử dụng các thành phần kỹ thuật thông thường của hệ thống internet hiện tại. Nó định nghĩa các input và output rõ ràng, cho phép kết nối với nhiều loại giao diện khác nhau.

Ví dụ:

  • Nếu có một MCP để xử lý dữ liệu từ Slack, team sẽ định nghĩa các API cho từng loại dữ liệu.
  • Nếu cần có các công cụ để đọc dữ liệu từ Google Sheets hoặc phân tích dữ liệu về tình trạng check-in trong tuần, team có thể tạo các MCP tool để xử lý những dữ liệu đó.

MCP sẽ là một thành phần trung gian để đồng bộ và xử lý dữ liệu từ nhiều nguồn khác nhau. Mọi người có thể truy cập các công cụ này từ Editor, Command Line, hoặc bất kỳ giao diện nào khác.

[1:01:07] Bản chất của MCP là nó sẽ đóng vai trò như một API Gateway để kết nối các công cụ. Nếu bạn cần theo dõi việc check-in hàng tuần của mọi người trong team, bạn có thể tạo một MCP để thu thập dữ liệu từ Knowledge Hub và Google Sheets, sau đó so sánh dữ liệu để xem ai đã check-in và ai chưa check-in.

Hệ thống hiện tại đang dừng ở mức độ triển khai MCP Server cơ bản. Giao diện hiện tại sử dụng Command Line để gọi MCP, nhưng về cơ bản team có thể mở rộng để kết nối với các công cụ khác nhau.

[1:01:43] Hệ thống đang tập trung vào việc triển khai cơ chế xác thực (authentication) và phân quyền (authorization).

  • Authentication – Xác thực người dùng để truy cập vào hệ thống.
  • Authorization – Phân quyền cho các hoạt động xử lý dữ liệu.

Hệ thống đang được sử dụng nội bộ trong team, chưa công khai ra bên ngoài. Nếu bạn muốn sử dụng MCP, bạn sẽ cần nhập vào private key để xác thực quyền truy cập.

[1:02:23] Về mặt kỹ thuật, MCP có thể mở rộng ra các thành phần khác nhau trong hệ thống. Mọi người có thể tích hợp MCP vào các ứng dụng hiện tại hoặc các công cụ hiện có mà không cần phải viết lại quá nhiều code.

Team vẫn đang thử nghiệm tính năng này và tập trung vào việc hoàn thiện các phần về bảo mật và quản lý quyền truy cập. Khi hệ thống đã ổn định, mọi người có thể tích hợp MCBP vào các quy trình xử lý dữ liệu hiện có.

[1:03:00] Chỉ là đang dừng lại ở đây thôi, chưa xử lý được các bài toán phức tạp về authorization. Sau khi hoàn thành các bước hiện tại thì mới đến việc xử lý các bài toán phức tạp hơn liên quan đến authorization và quyền sử dụng hệ thống. Mọi người có thể tập trung vào các vấn đề cơ bản trước đã.

Rồi, cảm ơn Huy nhé. Đây là một trong những phần phát triển kỹ thuật quan trọng của team. Nếu theo dõi các hoạt động trên tech và AI Club, mọi người sẽ nhận ra team đang tiến tới các bước tiếp theo trong quá trình phát triển. Về mặt kỹ thuật, mọi người nên chú ý vào các từ khóa quan trọng mà Huy vừa đề cập. Nếu chưa hiểu rõ thì có thể xem lại bản ghi để nắm được đầy đủ thông tin.

[1:03:45] Team core vẫn đang tiếp tục phát triển hệ thống. Yêu cầu tất cả các thành viên tham gia vào dự án để có thể transfer knowledge hiệu quả hơn. Dự án này là môi trường để mọi người học hỏi và thực hành.

Đây là cơ hội để các thành viên mới trong team tiếp cận và nắm bắt các khía cạnh kỹ thuật quan trọng. Nếu cảm thấy chưa sẵn sàng thì có thể tham khảo các phần hướng dẫn và tài liệu nội bộ để bắt kịp. Việc training sẽ được thực hiện trong quá trình làm việc chứ không có các buổi training riêng. Đây là môi trường thực hành trực tiếp để vừa làm vừa học.

[1:04:29] Bên cạnh việc phát triển hệ thống, team cũng đang thực hiện knowledge transfer từ các dự án đã hoàn thành. Dự kiến cuối tháng sẽ có một buổi tổng hợp lại các bài học rút ra từ các dự án này. Nếu ai chưa thực sự hiểu rõ thì có thể tham khảo hoặc hỏi các thành viên đã làm qua để nắm thêm thông tin.

Nếu cảm thấy chưa sẵn sàng hoặc cần thêm thông tin thì có thể hỏi trực tiếp các thành viên trong team. Mọi người có thể ping các thành viên có kinh nghiệm hơn để nhận được sự hỗ trợ.

[1:05:07] Team có hai nhóm khác nhau đang hoạt động song song:

  • Team của Tuấn đang phát triển một số game và ứng dụng nhỏ.
  • Team build đang làm việc trên các ứng dụng thử nghiệm để kiểm tra tính khả thi của hệ thống.

Các hoạt động này tương tự với các nhóm Build Club và AI Club trong team Foundation. Một số sản phẩm đã bắt đầu có output tốt. Tuấn và team đang phát triển một trò chơi dựa trên Turing Machine.

[1:06:38] Trò chơi Turing Machine mà team Tuấn phát triển được chuyển thể từ phiên bản board game thành phiên bản trên thiết bị di động. Mục tiêu của trò chơi là đoán một chuỗi gồm ba số. Để đoán đúng chuỗi số này, người chơi sẽ nhận được các clue (gợi ý).

Ví dụ:

  • Nếu gợi ý nói rằng “một trong ba số phải lớn hơn 1” → Người chơi có thể nhập số vào và hệ thống sẽ xác định xem đáp án có đúng hay không.
  • Nếu hai số sai nhưng một số đúng thì hệ thống sẽ phản hồi ngay để người chơi có thể tiếp tục điều chỉnh.

Luật chơi khá phức tạp nên có thể gây khó khăn cho người chơi mới. Tuấn và team đang tiếp tục điều chỉnh để trò chơi trở nên dễ tiếp cận hơn mà không mất đi tính thử thách.

[1:07:23] Tên trò chơi là Pocket Turing bởi vì phiên bản board game gốc của nó liên quan đến các thẻ đục lỗ – giống như cơ chế hoạt động của Turing Machine trong lập trình máy tính. Tuy nhiên, mình đã điều chỉnh và phát triển thêm các yếu tố mới để phù hợp hơn với phiên bản di động.

MÌnh có kế hoạch tinh chỉnh và mở rộng trò chơi trong các phiên bản tiếp theo. Ngoài ra, cũng đang kiểm tra xem có thể triển khai thêm các tính năng thu phí hoặc các tùy chọn nâng cao để tăng khả năng monetize.

[1:08:16] Mình đang thử nghiệm phiên bản beta của trò chơi. Trò chơi đã hoàn thiện về mặt gameplay và người chơi có thể trải nghiệm trọn vẹn các tính năng. Bước tiếp theo là thử nghiệm với nhóm người dùng rộng hơn để thu thập phản hồi và cải thiện sản phẩm.

[1:09:15] Mục tiêu tiếp theo là đưa trò chơi vào App Store và Google Play để tiếp cận nhiều người dùng hơn. Trước mắt, team muốn đảm bảo trò chơi hoạt động ổn định và không phát sinh lỗi nghiêm trọng.

Tuấn kỳ vọng trò chơi sẽ thu hút được ít nhất 100 người dùng trả phí trong giai đoạn thử nghiệm đầu tiên. Nếu nhận được phản hồi tích cực sẽ mở rộng thêm các tính năng mới và cải thiện trải nghiệm người chơi. Mong nhận được phản hồi từ các thành viên khác để có thể điều chỉnh và hoàn thiện sản phẩm tốt hơn. Tuấn đã chia sẻ link tải trò chơi cho các thành viên trong team để mọi người có thể trải nghiệm và đóng góp ý kiến.

[1:10:13] Nếu anh em hứng thú với việc build sản phẩm thì giai đoạn này là thời điểm phù hợp để bắt đầu. Trước đây team đã thử nghiệm nhiều lần nhưng lần này là cơ hội tốt để làm bài bản hơn. Việc phát triển các sản phẩm nội bộ không chỉ giúp cải thiện năng lực kỹ thuật mà còn mở ra cơ hội thương mại hóa trong tương lai.

Ngoài game của Tuấn, team đang phát triển thêm các công cụ khác. Nếu có ý tưởng hay, anh em có thể đóng góp để cùng xây dựng và thử nghiệm. Cách bán hoặc thương mại hóa sản phẩm thì tính sau, quan trọng là hoàn thiện các tính năng cốt lõi trước.

[1:10:58] Tiếp theo là phần của An. An từng làm một tool gọi là Rec để tổng hợp thông tin theo dạng giống với hệ thống của Apple. Phiên bản 1 của Rec yêu cầu người dùng tự sắp xếp thông tin, còn phiên bản 2 hiện tại đã được tích hợp AI để hỗ trợ sắp xếp tự động.

Tuy nhiên, AI vẫn có một số hạn chế trong việc nhận diện nội dung đầy đủ. Đôi khi AI không thể xác định được toàn bộ ngữ cảnh nên kết quả trả về chưa thực sự hoàn hảo. Tuy nhiên, các nội dung quan trọng vẫn được sắp xếp và hiển thị đầy đủ.

[1:11:56] Tool này đang trong giai đoạn hoàn thiện, nhưng các chức năng cốt lõi đã ổn định. Hiện tại, team đang tập trung vào việc cải thiện phần giao diện và tối ưu trải nghiệm người dùng. An dự kiến sẽ tiếp tục phát triển thêm các tính năng bổ sung để hỗ trợ người dùng tốt hơn.

[1:12:51] Các dự án của team hiện đang ở giai đoạn thử nghiệm và cải tiến. Nếu ai có thắc mắc hoặc góp ý, có thể trực tiếp trao đổi với An hoặc các thành viên khác trong team. Hiện tại, các dự án đã showcase gần hết. Các phần chi tiết hơn sẽ được đề cập vào buổi sau.

[1:13:57] Bên đội mình, anh luôn nói về chuyện kiến thức liên quan tới liquidity và game in general, thì anh em thật sự muốn team mình đẩy theo hướng đó một chút. Vì nó có lợi cho gần như là cái life skill luôn, đúng không? Nên anh muốn team mình đi theo hướng đấy trong đợt này. Mấy anh em, đặc biệt là những người hứng thú với trading, tức là lấy data về để tìm kiếm cái Alpha trên đó, Intel trên đó, để ra được những cái market-making dựa trên điều kiện nào đó.

[1:14:43] Nó là một cái, hoặc có thể đi xa hơn để làm một luồng rất tuyệt vời. Hình như hiện tại chỉ là ước mơ của anh thôi. An đã làm được một version, anh thấy khá ok. Đây là cơ hội để cho anh em biết trong team đang có những tiến triển như vậy. Đang chạy ha, mời An. Nói chung là game kiếm tiền thôi. Coi tụi nó kiếm tiền sao thì mình làm vậy. Mấy cái thường thường thì có biết một cái gì để thử, nó cũng là dạng Delta neutral, đúng không? Thì mình cũng research những thứ đó. Rồi đi build và research xong để có kiến thức ship.

[1:15:30] Chơi cái cột này hết thôi, không nhìn tới đâu nữa. Mọi người thấy màn hình terminal chưa? Có thấy chưa? Có thấy rồi, ok, chạy để chạy thử. Chắc phải zoom lên, zoom lên một hai level, hơi nhỏ, rồi ok rồi. Đây là arbitrage để ăn funding free, thì có nhiều thể loại arbitrage. Cái này chỉ là một trong những loại đó thôi, ăn trên chênh lệch phantom giữa các sàn. Đang tập trung vào ba sàn: Binance, OKX , thằng OKX này sàn của nó không có nhiều dữ liệu lắm , nên em có cái diagram cho cái đó không, An?

[1:16:26] Nghĩ mọi người sẽ hơi khó hình dung. Nhìn cái này chắc không hiểu nó là gì. Có diagram không? Ok, không có vẽ à? Có cái này, to, nhưng là lý thuyết, không cụ thể ra được high level. Không thấy, chắc phải ngồi vẽ lại sơ sơ. Thấy chưa? Chắc nhìn hình của anh đi, hình của anh, biết ngay là cái này luôn. PRL à? Ủa, nó đang chạy lộn, quên, nó đang vào mấy cái socket của…

[1:17:47] Tụi nó để lấy real-time data về. Đang lấy dữ liệu từ bao nhiêu account? Ba cái: Binance, Bybit, với cái gì nữa? Ok rồi, init để lấy giá về, đúng không? Lấy giá, lấy funding, lấy phí chưa? Lấy mấy cái data như phí thì đang code theo calculation, chưa xài để lấy về. OKX chắc không có. Mấy cái trade này thì thường chỉ nằm ở hai cái chính: Binance, Bybit. Ừ, setup ok rồi, nó sẽ có mảng thể hiện cái vị nào đang có chênh lệch funding, thì có profit. Em tính được nếu mình vào thì nó sẽ bao nhiêu. PH là số lần thu funding để hòa vốn phí, monitoring cái cao nhất giữa hai sàn. Bước một là lấy chênh lệch funding giữa hai bên, đúng không? Không, em nói là lấy trên ba exchange, so với góc của nó vẫn là exchange net, đúng không? Ừ, exchange net tính sau thôi.

[1:19:49] Funding thì giả sử tụi nó thường, trên lập giá thì không có nhiều, kiểu một thằng dương, hai thằng đều dương, hoặc hai thằng đều âm, thì chênh lệch ít hơn. Thật ra mình đặt counter trên cái chênh khác, chỉ là offset giá di chuyển, để không lỗ bởi giá. Trên exchange net, không có chênh lệch đó, mình làm funding lúc nào cũng bằng 0. Vì không có phí swap, thay vì counter trên sàn khác bằng cái đó, mình counter lúc funding bằng 0. Hiện tại chấp nhận ít lợi hơn, nhưng version đầu tiên vậy.

[1:20:33] Lấy giá, lấy funding, rồi coi có deploy capital thôi, đúng không? Chạy thử chưa? Chưa đổ tiền vô. Ừ, cái này kiểu game scale, cần nhiều tiền mới ăn, vài trăm ngàn thì vô không thấy gì. Hiểu, ok. Về kỹ thuật thì em làm gì? Từ lúc price crash, em làm những gì?

[1:21:25] Đầu tiên em research chart trước, coi nó thế nào, có chênh lệch gì không. Xong rồi ship, code hết bằng Cloud 3.7. Phải lấy data sàn trước qua socket, từ API dock của sàn, quăng lên WebSocket client. Sàn nào cũng có dock, lấy về ship lên, tự view được.

[1:22:15] Web cho ba sàn xong, có form đầy đủ. Sau đó build chart, giải thích cho nó, build từ từ. Check data, sai thì tự build sample để đảm bảo data đúng. Vì format giữa các sàn khác nhau.

[1:23:01] Khác hết, nên cần test data valid mới compare được. Tiếp theo build con để vào lệnh, khi phát hiện thì có thằng đứng ra vào lệnh, watch bot xem lỗ không, làm từ từ, hợp lý. Quá trình hết bao lâu? Một tuần.

[1:23:58] Bước tiếp theo của tool này là gì? Em sẽ check data trước, xem sàn nào dễ kiếm tiền, có lời. Quản lý rủi ro, lấy phí structure của sàn. Vì phí ảnh hưởng lớn, phải tính chính xác, đảm bảo lời mới vào lệnh. Có back system không? Có history để backtest không? Có, nhưng không chính xác.

[1:25:38] Đây là showcase kỹ thuật, hướng này team tự lập, ok. Anh em showcase game trading, có bước đẩy tiếp, đang trên đường làm cái muốn làm, rất good. Công nghệ, techno house, xài thế nào thôi. Quan trọng nhất là…

[1:26:19] Hoạt động team hiện tại vậy nhé. Productivity gần đây bắt đầu sync. Tom comment trước, productivity team giờ bao nhiêu? 2/10 hay 4/10? So với 6-7/10 cần, anh thấy setup tốt rồi.

[1:27:01] Bước tiếp theo về mặt catch up cái công nghệ tool link để hỗ trợ mình vận hành đội theo mô hình này, nó đang được improve từ từ lên. Bên thị trường, thị trường funding nói chung và những sản phẩm bắt đầu cũng rục rịch quay trở lại. Người ta thấy công nghệ ổn định hơn. Bên crypto thì do macro ảnh hưởng nhiều, nhưng cứ có trend nào về tech là sẽ vô cắn thôi, là vậy ha. Anh đang thấy sắp tới tín hiệu để nó resume lại thì đâu đó khoảng 50/50. Trước đó anh nhìn thì cái market rất tệ, kiểu mọi thứ chưa sẵn sàng. Dù có học nhiều, làm nhiều thì cũng không ra kết quả liền.

[1:27:40] Nhưng đợt này anh nghĩ mấy anh em sẽ phải có sự yêu cầu về chuyện tham gia mấy cái này ha. Tuần sau chắc nhờ Huy, Tom với Thành thống kê lại, xem ngoại trừ dự án anh em đang làm thì hoạt động tham gia những dự án side project như vậy, anh em nào đang làm gì ha. Đó là thần sau nội dung, thì cũng trao đổi gần hết rồi. Tuần sau còn một số cái core flow tiếp, nhưng chắc cũng không ảnh hưởng quá nhiều tới mọi thứ.

[1:28:22] Hôm nay là ngày 14, hy vọng đến cuối tháng này, buổi họp team tiếp theo sẽ show được nhiều progress hơn. Tất cả những thứ mình đang làm rất quan trọng ha. Toàn bộ này đều đang được đưa lên Memo, tụi anh đang sử dụng Memo đó không chỉ để share trên đó không ăn thua.

[1:29:01] Shill khắp nơi mấy công ty khác mình biết, bắt đầu mở rộng network ra để xem tìm kiếm user cần thiết. Chuyện là mình biết những thứ này rồi thì làm sao mình mound được khả năng mình profit từ kiến thức của mình, ý là vậy. Ok ha, đó là cái skin mà team đang chạy theo. Tóm lại, thị trường nhận định đang như vậy. Tuần sau mấy anh em sẽ phải đăng ký làm cái registration vô cho những cái phần, với lại Huy, Tom và Thành là những bên mạng bắt buộc.

[1:29:45] Còn bên mấy cái hobby club, như kiểu Build hay gì đó, thì anh không yêu cầu cao vào bên đó, ra cái kỹ thuật để apply, nó cũng không quan trọng lắm. Quan trọng là output nhiều hơn. Hai nhóm khác nhau: một nhóm là những phần mà core project mình sẽ làm, tập trung vào làm sao tăng activity, tăng cái knowledge base của mọi người; còn cụm kia tập trung vào cái skill set, chuyện develop product sao launch, làm sao làm onboarding tốt hơn, user các kiểu. Là một cái nhóm skill set khác.

[1:30:27] Đặc biệt là Huy, Huy đang co cho cái việc quay trở lại office để bắt đầu làm shadowing cho chuyện knowledge transfer, thì nếu được thì cứ tiếp tục để nó diễn ra. Rồi xem số liệu như thế nào thì report lại cho anh ha. Hopefully khi nào có con số đây thì mấy anh em xem thảo luận tiếp, làm sao setup cái vụ shadowing đó trên mấy cái dự án mà mình, mấy cái site mà mình tham gia, để có cái case share với nhau ha.

1:31:05 Toàn bộ là vậy. Nếu bây giờ không có gì khác thì chắc mình kết thúc ở đây. Đây có bao nhiêu bạn nhờ? 28 bạn hả? Không, đang bao nhiêu bạn trong con này nhờ? Chuẩn bị spam ICY, có vấn đề để transfer ICY chưa? Để cái này mai mốt lấy acc anh, hoài căng quá. Có vấn đề trên ICY nhờ. Mọi người ra random nha, giật cô hồn nha. Amount 28 thì mình sẽ drop 14 token ICY, entry là 14 rồi. Xin mời, duration là 5 giây. Ok, let’s go. Một ICY hồi nãy là tương đương khoảng 100 Satoshi rồi đó.

[1:32:09] Tuần sau lịch vậy nha, mọi người xem phối hợp với nhau để làm việc cho hiệu quả rồi. Bye bye.

English transcript

[05:30] Hello, can you hear me? Oh, okay, it’s fine now. Today, I think we’ll start a bit early. Today’s session will probably combine with the brother in the meeting for a little bit. One part will be to do a showcase, the second part is that the brother will summarize some things that were discussed with the guys previously. The second and third parts are that we’ll start letting the guys register for tasks. For now, to make it easier, I’ll probably let Huy Nguyễn go first to show the parts related to Huy, which involve ICY a little, and then show some tech stuff that our team is currently working on. This will give me a snapshot of how the tech team is doing right now. Then, moving forward, what our team needs and what the guys can contribute to it. Alright, let’s get started.

[06:35] Huy, where’s Thành? Let’s give them the stage now. Okay, for the first content, let’s start with ICY Swap. We announced it, last week or this week it was deployed, so now how are the differences, I’ll probably ask Huy to go over that whole series again.

[07:29] Hello, alright, I’ve seen the screen already. So now everyone can go to the ICY Swap page to swap. Here, I’ll show the data. But up here, everything is fully ready now. The only thing left to do is that we’re currently reviewing the ICY numbers. Because previously, when we were operating, we operated by pegging the ICY price, so we didn’t really care much about the circulating supply. So there were some cases where we put it into the team’s wallets or transferred it to Mochi Balances for me or for brother Bảo. Those things need to be reviewed again to get the correct circulating supply number. Because now we’ll sit down, and the price will be dynamic based on the pool, so we need to check that again, and it’s almost done.

[09:09] Now, the only thing left is brother Bảo’s account that needs to be checked again. I remember there was a time we transferred to brother Bảo, so now we’re reviewing that part, doing the addition and subtraction, and cutting that part out of the circulating supply, then this number will come out correct. For now, if anyone wants to swap to support, they can swap on this page. That’s the current schedule. I’ll show the list of our current Holders so the guys can see, probably need to know a bit more. Up until now, people participated without paying much attention, but this time we need to be more mindful.

[09:51] Our ICY is deployed on Base, right? So when the guys go into the Holder list, everyone will see a list of all the wallets currently holding our team’s ICY, which are the CCK Holders. That’s one thing. And then the link to access this, Huy will share it, I guess. Because if people go search for it, they probably won’t find it.

First, the guys need to understand this. Moving on to this part now. I think the guys need to pay more attention to this part. It’s become the norm in the tech world already, no need to do anything new anymore. So if the guys grasp this, it’ll be better.

[10:33] Our ICY is now listed. In this list, there are minter wallets, wallets used to budget for activities, and some wallets holding large amounts of ICY. Activities related to staking ICY will be rolled out gradually in the coming time. This is the first piece of information the guys need to understand clearly.

[11:15] Huy, demo the swap process for us. Does anyone have a Bitcoin address with some ICY? Is Vincent here? Okay, now let’s try swapping from ICY to Bitcoin. The current price is calculated dynamically based on the circulating ICY amount and the pool. The swap function is very simple, just enter the amount, press swap, and it’s done.

[12:27] Wait, don’t enter a fake address. Okay, it’s good now. The first frame is ICY as usual. Below it, it’s displaying the unit in satoshi, which is the smallest unit of Bitcoin. When you enter the amount, it will automatically convert. However, the current exchange rate is slightly off, around 1.2 instead of 1.5. This is probably a small calculation error, we can fix it.

[13:28] You need a minimum amount of ICY to swap. Try entering 30 ICY and see how it goes. Refresh it and check if it works.

[14:43] It seems like there’s not enough money in the wallet. Do you have ETH on Base? Transfer it to Base and check again.

[15:51] It’s not that error. The issue is that the account hasn’t been registered, so it can’t perform the transaction. We’ll fix that part later. The goal here is to help everyone understand the swap mechanism and how token pricing works better. If you understand it well, it’ll be easier to manage tokenomics later on.

[16:47] Huy, quickly explain the pricing mechanism again. Last time Quan demoed it but didn’t go into detail about that part. The price of ICY is determined by the minting mechanism, meaning the price won’t fluctuate heavily if someone swaps a large amount. It doesn’t operate like an automated market maker (AMM) mechanism; the price will be controlled through the minting mechanism. This mechanism helps keep the price stable even with large transactions.

[17:43] It completely depends on Bitcoin. So if Bitcoin’s price goes up, the amount of ICY you guys are holding will increase in USD value. As for the minting mechanism, Huy, explain a bit more. Generally, our overall mechanism so far is that we fix ICY’s value to USDC. You guys don’t need to worry too much, just understand simply that one ICY is equivalent to 1.5 USD.

[18:37] This assurance part is to help the operating team ensure that by the deadline, USDC will be added into the contract for everyone to swap. The swap rate in the old contract was fixed at 1.5 ICY, but that was the old model. Our new model is more flexible. If you guys have used Uniswap or other AMMs (Automated Market Makers), it’s somewhat similar. Here, the mechanism works with a liquidity pool underneath, which contains both ETH and USDC. Depending on the pool’s situation at that time, the exchange rate will be adjusted based on the amount of ETH and USDC in the pool.

[19:18] Our mechanism works similarly. The price of ICY will be determined by the amount of Bitcoin in the pool and the amount of ICY currently in circulation. The formula is simple: we have the amount of ICY (X), we have the amount of BTC (Y) in the pool, then X/Y will give us the value of one ICY in terms of BTC. This formula is basic mathematics, nothing complicated.

[19:55] Due to our operating mechanism, there will be two moments that change liquidity:

  1. The first moment is every month when the operating team adds more BTC into the pool to cover the costs of the team’s activities. At this point, the price of ICY will increase slightly because the amount of BTC in the pool increases.
  2. The second moment is when the team adds more ICY into the pool (minting more). When more ICY is minted, the market price of ICY will decrease because the amount of ICY in the pool increases.

[20:35] The two cases above will directly affect the price of ICY. However, if the price of Bitcoin changes, the USD value of ICY might change, but the price of ICY in terms of BTC will not change. The market impact from Bitcoin is an external factor and does not directly affect the minting or the value of ICY in the pool.

[21:12] If you guys have any more questions, feel free to ask, and we’ll answer them later. Oh, there’s a question about swapping back from BTC to ICY, right? Currently, that function isn’t available. Right now, we only support swapping from ICY to BTC, not the reverse swap. Meaning you can buy in, but selling out isn’t supported yet.

[21:40] Thank you, Huy. Anything else to note? One thing to note is that we’re still in the testing phase, so there might be some exceptional cases. For example, some situations might arise during swaps or when liquidity isn’t sufficient. Fundamentally, though, the current flow is still operating stably.

[22:00] Like the minimum ICY amount required to swap. Because essentially, our team is covering the gas fees for transactions on ETH, on Base, and even on BTC, we’re kind of limiting it so that the ICY amount swapped needs to be a bit higher. This is to avoid situations where people swap just 1-2 ICY to test, which would cost gas fees, so we’ve set it at around above 20 ICY to allow swapping on the web.

The second thing is that since minting more ICY will change the market price, I’ve disabled the part about our previous salary advance mechanism.

[22:37] Meaning if everyone advances salaries at the same time, it would affect the price, right? So the lesson learned from this is that after this round, there are a few points I’m noticing. Our team is starting to focus on building tools to support our operations. These are also some new experiments and some things that genuinely support our activities. But after finishing these tasks, we’ll produce some articles related to them. So if any of you didn’t participate in those projects earlier, you can look back at those articles to understand the game, the knowledge gained from that round, and what the guys working on those projects achieved.

[23:24] So with this ICY Swap round, we’ll probably get two or three articles, right? Yes, like three articles. And if we want to write more, there’s still plenty to write about. Yeah, alright, take it slow and steady.

[24:02] After Huy’s part, I thank Huy and move on to the second topic related to what our team is currently doing. Brother Bảo, whoever wants to go first is fine, but I’ll probably let Thành speak first. Thành said it’s okay for him to go first, he’ll gather everything to let everyone know what stage the team is at. But I said let Thành go first because someone’s ringing the bell. Alright, I invite Thành to start.

[25:00] Everyone, our Memo is one of the big things this round, and we’ve upgraded its format to make it look a bit better. We always want to create content maps, things that we can read and upload here. But currently, that model isn’t really that effective anymore because new models compress data, and querying directly from there would be more efficient.

So the point is that putting ordinary knowledge onto Memo isn’t very suitable anymore. For this round, when reworking it, there’s one main idea I want to tell you all: Memo will now be used for one sole purpose , the knowledge gained from projects.

That’s almost like the new things that come directly from our team’s activities. In the future, it’ll mostly consist of what field it’s related to and what we’ve done in that field. There’s more to it , maybe after a period when they retrain the model, our data will become part of the shared knowledge for the whole community.

[25:39] And I think this part will be very helpful for things like retraining AI models later or for cases where we want it to provide automatic suggestions.

[26:24] The content will become part of that model, or if there are internet search tools, our articles might just be a small part of the referenced materials, like a small piece in a citation. That’s not a big issue. But overall, all this content will pretty much become the spirit of the team.

In this major upgrade, there’s one key point that Tuấn has completed, right? Tuấn, the part about syncing all the team’s data, especially the content, is currently being directed this way so the members can understand it better.

[27:00] Meaning after this round, the members participating in projects will tend to sit down together to review those projects more closely and determine exactly what the knowledge gain from those projects is. After that, the team will upload it to Memo as internal reference material for the team.

The second part is that at the end of each article, there will be a section related to a group of reading. This part isn’t fully complete yet, but the idea is that once it’s finished, there will be an additional section summarizing information about the article so readers can look up and learn more from it.

[27:47] In addition, all the data written by the team will be tagged with identifiers such as GitHub, Discord, or other internal channels. This data will be uploaded to a blockchain storage form on the Arweave (AV) platform , a decentralized storage platform. This ensures that the team’s content has a clear and transparent identifier.

On top of that, readers will be able to review the articles, rate them, or leave feedback directly on the articles. This is part of the new upgrade idea for the team’s Memo page.

[28:39] Previously, the team intended to use Obsidian to manage content, but it seems some members had difficulty getting familiar with that tool. Therefore, to make things simpler now, the team will switch to a more direct mechanism. Specifically, instead of having to go through Obsidian, members can submit content directly to the repository of the team’s shared library.

Members just need to input the content and submit it directly through this platform, without having to follow Obsidian’s mandatory workflow anymore. If someone still wants to use Obsidian, that’s fine, but if they don’t, it won’t affect anything. This is the most fundamental change in the team’s Memo system.

[29:24] Currently, the team is working on several main projects, including:

  1. Bitcoin Swap , already mentioned in the previous section.
  2. Memo , just presented.
  3. Two smaller projects:
    • Agentic , being developed by Quang and Huy’s group.
    • GitHub bot , being worked on by Thành’s group, currently in testing.

Now, I’ll probably hand it over to Thành to share more about these contents.

[30:32] This project was started over a week ago and has officially been running code for more than a week. Its main purpose is to create a reminder system. Previously, the team often encountered situations where, after creating a pull request (PR), people would leave it there, wait for it to finish running, and then forget about the need to review it. This tool will serve to track and update information about daily activities on GitHub or weekly activities on the team’s internal communication channels.

[31:18] This system is designed as a simple integration. The basic workflow includes several use cases, such as notifying the person assigned to review, interacting with the GitHub API, and posting information to internal channels like Discord or Slack. Currently, the team is testing it on Discord. Additionally, the team is experimenting with Agentic and a new framework called Mastra AI.

This framework is different from typical Python tools. Some team members aren’t familiar with working in Python, so the team wants to test whether using this new framework is more effective than current solutions. The framework supports features like setting up the environment, defining states to manage data, and allowing reconfiguration based on the team’s needs.

[32:19] The system’s structure has two main parts:

  1. Agentic app , This is the main application for handling the system’s activities.
  2. Discord app , This supports sending notifications to Discord.

Additionally, the system has a few auxiliary components, such as workflows to handle scheduled tasks, check, and notify developers if there are any pull requests waiting for review. If a pull request exceeds a certain amount of time, the system will send a notification to remind the person responsible for reviewing it.

[33:12] The Agentic app will expose a few APIs that allow chatting and tracking the status of pull requests. When a pull request is created, the system will automatically identify conditions like the pull request’s status (work in progress or not), the time it was created, and will notify the reviewer after about 30 minutes from the creation time. For example, if a pull request needs review but no one is assigned or it has exceeded the processing time, the system will automatically ping the responsible person again.

[35:02] Instead of having to track manually, the system will attach an agent to automatically monitor and notify through the system’s endpoint. In the logic part, the system will define specific conditions, such as only sending notifications if the pull request was created within 30 minutes or is in a work-in-progress state. If the pull request is updated or changes status, the system will automatically track and notify the developer to ensure nothing is missed.

[35:39] The system will operate based on standard code filters. Additionally, it will have some other workflows, like sending notifications at the end of the day to summarize the status of pull requests on Discord. The system will automatically send notifications about the number of open pull requests, their statuses, and the current review status. This is the main function of this tool , acting as a reminder tool.

[36:24] The system can also integrate with other chat tools. It’s simple , you can create an additional command and send a request to the system’s endpoint. These requests will be defined based on a specific schema, such as the input being a review ID or other information related to the pull request’s status. The system will take this data and display it on the interface that users frequently use.

[37:04] The backend processing of the system is handled through the Lippia tool, which formats JSON data into Markdown tables or data-binding formats. Currently, the team is testing these two processing flows before expanding to additional features. Once the system is stable, these workflows will be opened up for all team members to test and further develop.

[38:08] The system is designed to scale flexibly. Team members can independently develop and contribute different workflows. This system allows the creation of tools as standalone packaging units, which can then be combined to create more complex workflows. When wanting to release a new workflow, members just need to redefine the basic unit and integrate it into the system.

Expanding workflows will help the system grow horizontally (increasing the number of features) rather than vertically (developing existing features). As the number of workflows increases, the system will become more flexible and powerful.

[38:54] Fundamentally, workflows are considered the application layer, similar to previous data APIs. This system will operate at the tool level, but end users will interact with it through the workflow interface. Currently, no entity has successfully implemented this model on a large scale. However, GitHub has now expanded its API for developers to create extensions and integrate them directly into GitHub.

[39:40] Dify is building a platform to support developers in developing and deploying these tools and workflows more easily. The goal is to create a marketplace where tools and workflows can be distributed and used by various users. This system is similar to an open platform, allowing third-party developers to deploy their own tools and workflows.

On Dify’s platform, there are already about 50 different tools. Some tools were previously released as experiments, but due to a lack of clear direction and community support, they didn’t achieve the expected success.

[40:17] Some platforms in the past tried building similar models but didn’t succeed. The reason is that those tools were only built as forms, lacking the ability to interact with external data and unable to combine complex workflows. However, Dify is focusing on solving these issues to create a complete ecosystem for workflows and tools.

[40:59] These tools also allow users to push data from external sources into the system. Users can send data from external applications via Open Forms or APIs. Dify will automatically process and format the data for use in the system’s workflows.

[41:56] The team is focusing on two main development directions:

  1. Continuing to expand and develop existing workflows.
  2. Improving and optimizing current tools to support easier deployment and use.

The system is built based on common standards for tool and workflow design. The Smithery tool is currently acting as an Agent to manage workflows. Smithery can also be used as a Package Manager to install and manage tools within the system.

[42:53] Workflows will operate on the mechanism that if a workflow becomes popular, people can take it and use it as a tool. The nature of these tools is that they are designed to serve specific domains. For example, a tool for creating files, searching, or retrieving code files. It works like an SDK, meaning a library that you just need to import to use.

[43:37] Once integrated into the SDK, you can use the available methods to manipulate data. This allows easy integration into AI tools. Currently, only Cross directly supports these operations. However, in the future, it will be standardized so other tools can also integrate easily. The case of Manus is an example. Manus uses many different tools, but when compared to the agent system in Smithery, they are fundamentally two completely different layers.

[44:15] In Manus’s system, tools are combined to create more general workflows. These tools operate at different layers, while agents in Smithery are designed to work independently. The question is how to clearly distinguish the difference between Manus’s system and the agent system in Smithery. There’s a summary article about this posted in the AI Club channel , the main content discusses the ability to think (thinking) and the ability to use computers (computer use).

[45:09] The mechanism of the Manus system is a service-oriented system. To combine multiple tools into a single workflow, the execution steps need to be clearly defined. For example, step 1 uses which tool, step 2 uses which tool, and so on. This requires the steps to be specifically configured. However, the new system has the ability to reason and automatically determine which tools are needed to complete a task. This is the key difference between the new system and older systems.

[45:59] Specifically, the new system can recognize how many tools a task requires, which steps to go through, and can intelligently adjust the execution order. This is a special mechanism and a difference compared to older systems. In other words, it operates like a Supervisor , capable of reasoning and making decisions about the order and method of executing steps in a workflow.

[46:35] The Supervisor system operates at a higher layer than the agents in Smithery. Agents in Smithery are simply tools that execute a specific task, while the Supervisor has the ability to manage and coordinate the entire task execution process. Integrating the Supervisor allows the system to operate more flexibly while making it easy to expand and add new tools.

[47:33] The team’s goal is to understand how the system works and grasp the mechanics of managing workflows. If we can determine how to deploy and manage workflows, we’ll be able to select and use tools more effectively. This is what the team is aiming for , building a system capable of scaling and optimizing workflows.

[48:24] Next, the team will focus on building the MCP system. This is a new system designed to manage data and workflows. The team conducted a demo of this system about two weeks ago. The essence of the MCP system is to build an agent that operates on an existing platform. Users can quickly deploy and test the system through MCP.

[49:10] MCP will be a complete system, including a database and a server. This allows the system to operate independently and handle large amounts of data. Unlike older systems, MCP will allow users to adjust configurations and manage data more easily.

[49:58] The essence of MCP is an agent, defined with a specific input and output structure. This allows different systems to connect and interact with MCP through standard protocols. In other words, MCP can be integrated into any system via predefined protocols.

[50:35] MCP also allows users to manage data through the Knowledge Database, which is essentially a timescale database where all the team’s activity data is dumped. This is a time-series database that enables recording events in real-time, something backend developers will recognize as event sourcing or event logs. For example, it records information about team members, the system’s operational status, or other significant events.

[51:13] The Knowledge Database will store all the team’s activity data, including details like who performed which task, the system’s status at specific times, and other information related to the team’s internal operations. This allows the team to track and analyze work performance, thereby making reasonable adjustment decisions.

[51:51] The system’s concept includes a component called the Landing Zone. The Landing Zone means that all the data we currently have , about a dozen to tens of datasets (databases) , will be centralized here. Three to five years ago, if we wanted to build a data storage system, we’d create a bot to collect all the team’s activities and input them into our database.

With the new Meta model, all large data (Big Data) will be dumped into a temporary storage in the form of .dat files on S3 or GCS (Google Cloud Storage). The MCP will have the ability to read directly from the Landing Zone. If the system determines that the data in the Landing Zone is valuable and necessary, it can automatically convert that data into a Time Series Database (TSDB) for long-term use. This is the end game (final outcome) of this system.

The remaining issue will be building Use Cases based on the organized data in the system , in the direction the team desires. This is a key development direction for the MCP system in the near future.

[52:25] So currently, the team will have an old database system , a traditional table-based database located at the bottom of the system (visible in the diagram with blue blocks). Now, the team is adding two new components:

  • The Landing Zone component , located in the yellow block at the top of the system.
  • The Time Series Database (TSDB) component , directly connected to the old system’s components for data analysis and exploitation.

The team is storing raw data in the Landing Zone. Essentially, centralizing data in the Landing Zone is like rallying troops , gathering all the data in one place before deciding how to analyze and process it. This mechanism makes the system more flexible and easily scalable when new data is added.

[53:11] The special feature of this system is its ability to automatically convert data from the Landing Zone to the Time Series Database. This mechanism stems from the growing need for local data analytics. This is an emerging trend in the context of AI (Artificial Intelligence) development.

The rise of AI has increased the demand for real-time data analysis systems. When raw data is centralized in the Landing Zone, the system will automatically identify valuable data and transfer it to the TSDB for more detailed analysis. This is a significant step forward in building an efficient and adaptable data analysis system to market changes.

[53:45] Currently, the team can already run analytics directly on the data stored locally. This system allows running analytics right on the Data Lake without needing to transfer data elsewhere. For the data in the Landing Zone , the file packets that Huy is showing on the screen , this is the part the team needs to focus on researching further. This issue relates to text processing, so the guys need to pick up this topic. It’s not too difficult; it’ll probably take about half a day to grasp the basics.

The Prompt for searching and exploiting data is also quite fast and simple, not complicated. This is a part very worth experimenting with because it relates to the knowledge discovery mechanism in the system. This is one of the new upgrades Huy just mentioned.

[54:22] The most standout feature of the system in this upgrade is the Knowledge Hub. This is where the team will centralize all data to serve analysis and knowledge exploitation. The Knowledge Hub will become a common data pool for the entire team. Anyone can add data here, and the system will process and convert the data into a standard format.

The important thing is that once the system is fully set up, everyone in the team will have a common protocol to use. Different modules or components will be able to share a common data structure and access the Knowledge Hub directly. This will be the common foundation for syncing and processing data within the team.

[54:58] Regarding the database (DB), the system will have two layers:

  • Old DB: Used to support existing operations and process pre-structured data.
  • New DB: Designed to connect directly with the Knowledge Hub and support real-time data analysis.

The special thing is that the MCP will act as a protocol for different modules to communicate with each other. This means that any data needing access or processing just needs to be fed into the system’s correct pathway, and it will be automatically processed according to the standard structure. This is how the system unifies data and avoids conflicts when multiple data sources are processed simultaneously.

[55:43] From now on, the team will need to get familiar with the new data processing mechanisms. Everyone should take the time to learn more about the components in the new system. Once these components are stable, the team’s new projects will leverage these tools to deploy faster and more efficiently. This will be the main toolkit to serve future projects.

This system has the potential to become a requirement for upcoming projects. If you want to keep up with the new system, start by learning the basic principles of MCP and related protocols.

[56:40] Previously, when the team deployed systems on S3 or GCS (Google Cloud Storage), data processing took quite a bit of time. However, with the new mechanism, data from the Landing Zone will be processed faster and more easily.

The system has been tested on various platforms, including S3 and GCS. However, since the team’s current infrastructure runs on GCS, the data from the Landing Zone will be processed on GCS first. That said, technically, the system can expand to other platforms without major obstacles.

[57:45] The Landing Zone’s operating mechanism is quite simple:

  • Data from various sources will be centralized in the Landing Zone.
  • This data will be stored as Parquet files by day.
  • The system can read these files back through the Time Series Database (TSDB) mechanism.

Currently, some sample Parquet files have been created and are being tested. If needed, the team can run a demo on these sample data sets to check the system’s consistency.

[58:24] The team’s activities, like AI sub or Memo, are also fully pushed up here. The task of the Landing Zone is to store all the data the team wants , anyone who wants to store something can push it all here, and then the system will decide how to process that data. The system has also provided some tools for people to push data up, such as API proxies to forward events. If anyone wants to push information to the Landing Zone, they just need to call the API.

Memo is currently using this mechanism to pull data from social platforms and sync it into the system. This mechanism has been successfully tested. For more specific data types like Discord messages or data from Basecamp, the team needs to build crawlers or connectors to collect the data. Currently, the team already has some ready-made templates for these data types.

[58:59] For the next development direction, the team will focus on exploiting data from the Landing Zone. If you want to join this project, the advice is to start with a specific vertical. For example:

  • Identify a clear use case.
  • Find out which data is needed for that use case.
  • Redefine the data exploitation mechanism in a top-down approach.

Instead of storing whatever data seems interesting, the team should think in terms of defining the use case first and then deciding what data to store. This helps the system operate in an organized and easily manageable way.

A specific example is if there’s a use case about Project Nghệ Nhân, the team would need to create a Git Agent to collect data from Git, then push that data into the Knowledge Hub via MCP. From there, the system would define data exploitation tools for this use case.

[1:00:16] Additionally, the team is developing a small MCP Server. This MCP Server is essentially a basic server, using standard technical components of the current internet system. It defines clear inputs and outputs, allowing connection to various interfaces.

For example:

  • If there’s an MCP to process data from Slack, the team will define APIs for each data type.
  • If tools are needed to read data from Google Sheets or analyze weekly check-in status data, the team can create MCP tools to handle that data.

MCP will act as an intermediary component to sync and process data from various sources. Everyone can access these tools from the Editor, Command Line, or any other interface.

[1:01:07] The essence of MCP is that it will serve as an API Gateway to connect tools. If you need to track everyone’s weekly check-ins in the team, you can create an MCP to collect data from the Knowledge Hub and Google Sheets, then compare the data to see who has checked in and who hasn’t.

The current system is at the stage of deploying a basic MCP Server. The current interface uses the Command Line to call MCP, but fundamentally, the team can expand it to connect with various other tools.

[1:01:43] The system is focusing on implementing authentication and authorization mechanisms.

  • Authentication – Verifying users to access the system.
  • Authorization – Assigning permissions for data processing activities.

The system is currently being used internally within the team and has not been made public externally. If you want to use MCP, you’ll need to input a private key to authenticate your access rights.

[1:02:23] Technically, MCP can expand to different components within the system. Everyone can integrate MCP into existing applications or tools without needing to rewrite too much code.

The team is still testing this feature and focusing on completing the security and access management parts. Once the system is stable, everyone can integrate MCP into their existing data processing workflows.

[1:03:00] It’s just paused here for now; we haven’t tackled the complex authorization problems yet. After completing the current steps, we’ll move on to addressing more complex issues related to authorization and system usage rights. For now, everyone can focus on the basic issues first.

Alright, thank you, Huy. This is one of the important technical development parts for the team. If you follow the activities on the tech and AI Club, you’ll notice the team is moving toward the next steps in the development process. Technically, everyone should pay attention to the key terms Huy just mentioned. If you’re not clear on them, you can review the transcript to get the full information.

[1:03:45] The core team is still continuing to develop the system. We request all members to participate in the project so we can transfer knowledge more effectively. This project is an environment for everyone to learn and practice.

This is an opportunity for new team members to get acquainted with and grasp important technical aspects. If you feel unprepared, you can refer to the internal guides and documents to catch up. Training will happen during the work process rather than in separate sessions. This is a hands-on environment where you learn while doing.

[1:04:29] Alongside system development, the team is also conducting knowledge transfer from completed projects. We expect to have a session at the end of the month to summarize the lessons learned from these projects. If anyone doesn’t fully understand yet, they can refer to or ask members who’ve worked on them for more information.

If you feel unprepared or need more details, you can directly ask team members. Everyone can ping more experienced members to get support.

[1:05:07] The team has two different groups working in parallel:

  • Tuấn’s team is developing some games and small applications.
  • The build team is working on experimental applications to test the system’s feasibility.

These activities are similar to the Build Club and AI Club groups within the Foundation team. Some products have started showing good output. Tuấn and his team are developing a game based on the Turing Machine.

[1:06:38] The Turing Machine game that Tuấn’s team is developing is adapted from the board game version into a mobile version. The game’s goal is to guess a sequence of three numbers. To guess the correct sequence, players receive clues.

For example:

  • If the clue says “one of the three numbers must be greater than 1” → Players can input numbers, and the system will determine if the answer is correct.
  • If two numbers are wrong but one is correct, the system will respond immediately so players can continue adjusting.

The rules are quite complex, which might be challenging for new players. Tuấn and the team are continuing to tweak it to make the game more accessible without losing its challenge.

[1:07:23] The game is called Pocket Turing because the original board game version involves punched cards , similar to how the Turing Machine works in computer programming. However, I’ve adjusted and added new elements to make it more suitable for the mobile version.

I plan to refine and expand the game in future versions. Additionally, I’m checking if we can implement premium features or advanced options to increase monetization potential.

[1:08:16] I’m testing the beta version of the game. The gameplay is complete, and players can fully experience the features. The next step is to test it with a broader user group to gather feedback and improve the product.

[1:09:15] The next goal is to bring the game to the App Store and Google Play to reach more users. For now, the team wants to ensure the game runs stably without serious bugs.

Tuấn hopes the game will attract at least 100 paying users in the initial testing phase. If we get positive feedback, we’ll expand with new features and improve the player experience. I’d love to hear feedback from other team members to adjust and perfect the product further. Tuấn has shared the game download link with team members so everyone can try it and provide input.

[1:10:13] If you guys are excited about building products, this is a good time to start. The team has experimented many times before, but this is a chance to do it more systematically. Developing internal products not only improves technical skills but also opens up future commercialization opportunities.

Besides Tuấn’s game, the team is working on other tools. If you have any good ideas, feel free to contribute so we can build and test together. How to sell or monetize the products can be figured out later; the priority is completing the core features first.

[1:10:58] Next is An’s part. An once made a tool called Rec to aggregate information in a format similar to Apple’s system. Version 1 of Rec required users to manually organize information, while the current Version 2 has integrated AI to support automatic organization.

However, the AI still has some limitations in fully recognizing content. Sometimes it can’t grasp the entire context, so the results aren’t completely perfect. Still, the important content is organized and displayed fully.

[1:11:56] This tool is in the refinement stage, but the core functions are stable. Currently, the team is focusing on improving the interface and optimizing the user experience. An plans to continue developing additional features to better support users.

[1:12:51] The team’s projects are currently in the testing and improvement phase. If anyone has questions or suggestions, they can directly discuss with An or other team members. For now, we’ve showcased almost all the projects. More detailed parts will be covered in the next session.

[1:13:57] On our team’s side, I always talk about the knowledge related to liquidity and game in general, right? We really want the team to push a little in that direction because it’s beneficial for almost like a life skill, you know? So I want our team to head in that direction this time. Especially those of you who are really interested in trading, meaning getting data to find the Alpha on it, the Intel on it, to come up with some market-making strategies based on certain conditions or something like that.

[1:14:43] It’s one thing, or it could even go further to create a really awesome flow. It feels like it’s just my dream for now. An has already made a version that I think is pretty okay. Just taking this chance to let you guys know that the team has this kind of progress going on. It’s running, right? Let’s invite An. Okay, okay, generally it’s just a money-making game. See how they make money, and we’ll do the same. The usual stuff has a bit of something to test, a bit of it is also in the form of Delta neutral, right? So we also research those things there. Then go build and research to have the knowledge to ship it.

[1:15:30] Play this column until it’s all used up, that’s it, no looking over there. Do you all see the terminal screen? Do you see it? Yes, okay, let’s run it. Let’s run it. I think we need to zoom in, zoom in one or two levels, it’s still a bit small, okay now. Yeah, this is the arbitrage to eat the funding free frost, right? There are many, many types of arbitrage like that. This is just one of those types, which is eating off the difference, the phantom bin, between the exchanges. We’re focusing on three exchanges: Binance, OKX , that devil OKX, their exchange doesn’t have too much stuff , so, do you have a diagram for that, An?

[1:16:26] I think it’ll be a bit hard for everyone to visualize. Looking at this, they won’t understand what it is. Is there one? Okay, no diagram? Oh, there’s this, big one, just theory, nothing concrete comes up at a high level? I guess we’ll have to sketch it roughly again. Do you see it yet? Maybe look at my diagram, yeah, my diagram, so you know it’s this right away. The PRL? Wait, it’s messed up, running wrong, forgot, it’s going into the sockets of…

[1:17:47] Those guys to pull real-time data back, and it’s currently pulling data from how many accounts? Three accounts , Binance, Bybit, and what? Okay, initialized to get the price back, right? Getting the price, getting the funding back, getting the price yet? Getting some data like fees and fee-related data, it’s kind of coded according to that calculation, but it hasn’t been used to fetch yet. OKX probably doesn’t have it. Those trades, okay, don’t have it, so usually it’s just on the two main ones, which are Binance and Bybit. Yeah, setup is okay, and then it’ll have an array to show which pair has the difference, the difference in funding, then it’ll have profit, and I calculate that if we enter, how much it would be. PH is the number, the number of times we collect the funding to break even with the fees. It’s monitoring, monitoring the highest between the two exchanges, that’s it. Step one is getting the difference, the difference in funding between the two sides, right? Between the two sides that I’m talking about, no. Because I said this is getting from three exchanges, so compared to its angle, it’s still on the exchange net, right? Yeah, exchange net is something calculated later because…

[1:19:49] Funding, let’s say normally, on the price setup, they usually don’t have much, like one is positive, two are positive, or two are negative, so the difference is smaller. Actually, we place a counter on the other difference, it’s just the offset, the price movement offset, so it doesn’t lose due to the price. On the exchange net, there won’t be that difference, we make the funding always equal to zero, right? Because there’s no swap fee there, and instead of countering on another exchange with that thing, we counter at the moment when the funding is also zero. Currently, we accept that it won’t be as profitable, but that’s how the first version is.

[1:20:33] bSo we get the price, get the top, get the funding, then see if it’s just about deploying capital, right? Have you tried running it yet? Not yet, haven’t poured money in. Yeah, this is like a scale game, you need a lot of money to profit, but with just a few hundred or a few thousand, it goes in, and it doesn’t look like much. Got it, got it, okay, understood. But on the technical side, technically, for me to do this, what did I apply from start to finish? From when it crashed, what did I do? Yeah…

[1:21:25] First, I researched that chart beforehand, checked how it was, whether it had this or that, all those things. Yeah, got those dots sorted. We’ll ship it for that, yeah, that guy will code everything with code, okay? Using this Cloud 3.7, right? First, you have to get the exchange’s data before calculating anything. The main exchanges will pull from sockets, and the setup is, first, on the API docks of the exchanges, right? This one, yeah, then pull their docks back, throw it to this guy, it ships up to the WebSocket client. Every exchange has docks, all of them, pull them back, ship them up, and it’ll auto-view.

[1:22:15] The web for all three exchanges is done, with forms and everything. After that, we start building it up, yeah, this part, this chart. The first step is probably explaining it to it and stuff, kind of it builds slowly up. Then check the data and all, if it’s wrong, it auto-builds itself. I built it, and it auto, every time there’s something new, it’ll auto-build a sample to check the data before finding it again for us. Cool, to ensure the data is correct or not. Because the thing between the exchanges, the format is different, the data format is…

[1:23:01] Different, everything is different, right? So to compare it all into one final form for it to compare, it needs a section to test pulling the data back, ensuring the data is valid, then it starts comparing. That’s the step. Next, it’ll be building things like, next is, yeah, building the guy to place orders. When it detects these, there’ll be a guy standing by to place orders, watching our bot to see if it’s losing or whatever, slowly, reasonably. The whole process took how long? About a week, yeah, cool, huh? So now the next step…

[1:23:58] The next step of this tool I’m working on, what’s the next step? I’ll check the data first, check the data to see which one makes money easily, which one is profitable, which one you put money into and it’s all profitable. There’ll be data to check those profits, then manage more of our stuff, like risks and all that, then, yeah, pull all the data back about the fee structure of the exchanges. Because if you use those trusts or whatever, the exchange fees affect the thing a lot, so you need the exact fees, then calculate…

[1:24:51] How to ensure it’s profitable in the end before placing orders, right? Next will probably be those steps. Okay, that’s the step, the step of when to place orders, that’s the final thing, right? The rest needs to filter the data first. Is there a back system built? Because I think this data, does it have history or not? Does it? Or is it just at that moment? It does, if you can get the history, it’s backtest history, but I think it’s not accurate, huh? Yeah, not accurate, not there. I don’t think so. The other stuff might have it, but this arbitrage is a bit hard to get accurate.

[1:25:38] This is a technical showcase. I think with this direction in the team, independently, our team, regarding this direction, it’s okay. You guys showcasing the trading game have started having steps that the team is pushing forward to do. I think fundamentally, fundamentally, you guys are all on a path, on the way to getting to what you want to do, which is very good. The thing is, with technology, with that tech know-how, how we bring it out and use it, right?

[1:26:19] The team’s activities in general are like this, okay? Regarding productivity, it feels like recently everyone has started syncing with each other to a certain degree. But with Tom, Tom is probably out, but Tom had a comment from before when you guys were sitting and chatting. We were thinking, what’s the team’s productivity level right now? How much would Tom rate it? 2/10 or 4/10, huh? If compared to the level we need, you guys at like 6-7/10, the general average, I think we’re in a very good setup right now.

[1:27:01] The next step regarding the quality, the technology tool link to support us in operating the team according to this model, it’s being improved slowly but surely. On the market side, the funding market in general and the products are starting to stir and come back. People see the technology becoming more stable. In crypto, it’s heavily influenced by macro factors, but whenever there’s a tech trend, they’ll jump in and bite, that’s how it is, right? I’m seeing signals for it to resume soon, about 50/50 right now. Before this, I looked at the market, and it was really bad, like everything wasn’t ready yet. Even if you studied a lot and worked a lot, results wouldn’t come immediately.

[1:27:40] But this time, I think you guys will need to have some requirements about participating in these things, okay? Next week, I’ll probably ask Huy,Tom and Thành to compile some stats, to see besides the projects you’re working on, what’s the participation in side projects like that, who’s doing what, alright? That’s the follow-up after the content, we’ve discussed almost everything. Next week, there are still some core flow parts left, but they probably won’t affect things too much.

[1:28:22] Today is the 14th, I hope by the end of this month, the next team meeting will show more progress. Everything we’re doing is very important, right? Another important thing is we have Sister Minh here, Nicki. Probably past the out time already. All of this is being uploaded to Memo, and we’re using that Memo not just to share on it , that’s not enough , but the channels we’re working on are being sent out…

[1:29:01] To everywhere, to other companies we know, starting to expand the network to look for necessary users. The thing is, we know these things already, so how do we mound our ability to profit from our knowledge? That’s the idea, okay? That’s the skin the team is following. In summary, the market assessment is like this. Next week, you guys will need to register for those parts, and Huy, Tom, and Thành are the mandatory segments.

[1:29:45] As for the hobby clubs, like Build or something, I don’t have high demands there, producing technical stuff to apply, it’s not that important. The output matters more. Two different groups: one group is the core project parts we’ll work on, focusing on how to increase activity, increase everyone’s knowledge base; the other group focuses on the skill set, how to develop products for launch, how to do onboarding better, users and all that. It’s a different skill set group. You guys next week jump in and start thinking, especially…

[1:30:27] Especially Huy, Huy is co-handling the return to the office to start shadowing for knowledge transfer. If it works, just keep it going, then see how the numbers look and report back to me, okay? Hopefully, when we have the numbers, you guys discuss further, figure out how to set up that shadowing on the projects, the sites we’re involved in, to have cases to share with each other, right? Like Sister An, finishing this in a week is super solid, doing everything herself, using new workflows and all, it’s great…

[1:31:05] Alright, you guys, that’s the whole thing. If there’s nothing else now, we’ll probably end here. How many people are here? 28 people, huh? No, how many in this call right now? Preparing to spam ICY, is there an issue with transferring ICY yet? Everyone go random, grab it like ghosts, okay? Amount is 28, so we’ll drop 14 ICY tokens, entry is 14 already. Go ahead, duration is 5 seconds. Okay, let’s go. One ICY earlier was about 100 Satoshi already.

[1:32:09] Now starting, don’t know when the boss updates the multiplier price, just estimate it for now. Today’s early, next time seeing Bitcoin, it looks cool. Happy Weekend, bye bye everyone.

Tagsdiscordoffice-hoursOGIF

Dwarves is a research-driven software company. They build and run fintech, trading, and cloud platforms.

Subscribe to Dwarves Memo

Receive the latest updates directly to your inbox.

Join our Discord